Its almost a month since I promised Heikki Tuuri to answer Innodb Questions. Heikki is a busy man so I got answers to only some of the questions but as people still poking me about this I decided to publish the answers I have so far. Plus we may get some interesting follow up questions out of this.

I had added my comments to some of the questions. HT will stand for Heikki Tuuri in the answers and PZ for myself.

Q1: Why did you decide to go with gzip compression instead of implementing “classical” approach of index prefix compression ?

HT: The reason is that index prefix compression prevents one from using a binary search on a B-tree node. We could not compare a search key K to an index record R if we only knew the suffix of R. There are, of course, hybrid approaches where some prefix information is stored, and a search almost as efficient as a binary search can be performed.

But InnoDB’s adaptive hash indexes require that the prefix is stored in every record R. An adaptive hash index tries to guess where our search would end in the B-tree. To verify that we arrived at the right position, we need to know the whole record R.

Also, a gzip compression potentially compresses the database more than just prefix compression. The downside in gzip is increased usage of CPU time.

PZ: We will see how it plays when we can see more benchmarks. The big problems I see so far with this feature are ease of use and requirement to “guess” how your data will compress for the whole table. Among other things compression for data pages and uncompressed index pages can be significantly different.

Q2: Does Innodb has pointers to the next/previous page in index tree leaf pages ?

HT: Yes

PZ: It is great as it can help to make full table scans and index scans more efficient. I can’t wait for ability to create physically sorted indexes with Innodb (with index built by sort) this is when this should be helpful the most.

Q3: Does Innodb secondary Indexes trees are allocated in two extents same as primary key tree or stored in the same extent ?

HT: An InnoDB extent is a contiguous block of 64 pages, 16 kB each. Each B-tree index in InnoDB occupies two SEGMENTs. One segment is for the non-leaf nodes, and the other for leaf nodes. The first 32 pages of a segment are allocated from ‘fragment extents’ where any individual page can be allocated to whatever use in whatever segment. After that, a segment always reserves whole 64 page extents.

Thus, the answer to the question is: for small tables, everything can reside within a single extent. For big tables, a secondary index reserves different extents from the clustered index.

Q4: Does Innodb ever merges sequential pages together if they become almost empty

HT: Yes. If a page becomes less than half full, a merge is attempted.

btr0cur.h:

/* In the pessimistic delete, if the page data size drops below this
limit, merging it to a neighbor is tried */

#define BTR_CUR_PAGE_COMPRESS_LIMIT     (UNIV_PAGE_SIZE / 2)

Q5: When Innodb free space becomes available for use within same object? When does Innodb make it available for other objects.

HT: Free space can always be recycled within a segment. A segment can release free space to other segments, if a 64 page extent becomes totally empty, and also it can release individual pages from its 32 ‘fragment extent’ pages.

PZ: This is the reason why when you delete a lot of scattered rows you may not see a “free space” in Innodb tablespace to grow significantly.

Q6: Does Innodb policy replacement algorithm takes into account page position in btree index ?

HT: No. It is a pure LRU algorithm.

PZ: This is one of the things which we would like to play with - I would expect serious improvements are possible especially on high IO pressure workloads.

Q7: Does Innodb has any protection from pages being overwritten in buffer pool by large full table scan

HT: No

PZ: Another possible area of optimization. I frequently see batch jobs killing server performance overtaking buffer pool. Though full table scan is only one of replacement policy optimizations possible.

Q8: How do you assess current state of Innodb scalability with multiple threads and multiple concurrent transactions ?

HT: The scalability in my opinion is ‘mediocre’, and we are working on improving it.

PZ: Thank you for honest acknowledgment and I can’t wait to get hold of further improved versions.

Q9: Do you favour database “self tuning” or prefer to expose tuning options to be available to the user.

HT: I favor self tuning.

PZ: I also like self tuning in theory. But I really like to have tools to steer the database behavior in the cases when self tuning gets it wrong.

Q10: When Innodb decides to schedule sequential read-ahead, random read ahead ?

HT: InnoDB schedules a sequential read-ahead when it notices an ascending access pattern that passes an extent boundary. Roughly, if most of the pages in the extent have been accessed, and in an ascending order of the
file address, then InnoDB schedules the read of all the 64 pages of the extent where the next index page in the ascending order is. InnoDB has a similar heuristic for descending index scans.

The InnoDB sequential read-ahead is not optimal at all. It should schedule the read of the next extent when we are in the middle of the processing of the previous extent.

Random read-ahead means that when InnoDB notices that if at least 13 pages in an extent have been accessed very recently, then InnoDB reads in all the rest of the pages in the extent.

PZ: Interesting enough, there was some work done by DIKU students improving algorithms used for read ahead and results were significant. They however were not merged in Innodb mainline yet.

Q11: If read-ahead is happening and Innodb needs to access one of the pages being fetched does it has to wait for whole read ahead request to complete

HT: Unfortunately, it often has to wait. A read-ahead of a 64 page extent is
often done as a single 1 MB file read.

PZ: “often” a bit stikes me here. I thought it would be always single read, typically 1MB in size. I should also mention a post on this topic once.

Q12: If read-ahead request was placed to the queue but did not start executing yet will innodb has to wait for it to complete or can just go ahead and read page it needs

HT: InnoDB has to wait.

PZ: This one is a bummer. I thought Innodb will make sure to schedule synchronous wait in front if read-ahead IO has not been started already. The interesting question it brings - how many read-ahead requests can be queued at once.

Q13: Is there any IO concurrency control - how many random and sequential read aheads can be happening at the same time

HT: All read-aheads are performed in the Unix version with a single thread. Only one read-ahead can be happening on Unix at a time. On Windows, InnoDB uses native async I/O, and can perform many read-aheads at the same time.

PZ: Another thing I’d like to experiment with. I would expect you can gain significantly with multiple IO threads on systems with large amount of hard drives. Google has Patches which let you to try it out.

Q14: Are there any plans to fix Innodb so it unlocks (or never locks) the rows if they were not matched by query where clause when it was not resolved by index

HT: That is already implemented in 5.1: if you set the transaction isolation level READ COMMITTED, then InnoDB normally does not lock the ‘gaps’, and it does not lock rows whose latest committed version does not match the
WHERE condition in a search. Please use this with care: you MUST use row-based binlogging and replication, and remember that the execution is not serializable.

PZ: Cool. This is one of little known new features in MySQL 5.1

Q15: How frequently does Innodb fuzzy checkpointing is activated

HT: InnoDB flushes about 128 dirty pages per flush. That means that under a heavy write load, a new flush and a checkpoint happens more than once per second.

PZ: Not what this answers question exactly. So is it activated as soon as 128 pages must be flushed ? If so how this is discovered when. I think fuzzy checkpointing one of little known aspects of Innodb operations while I see it causing problems every so often.

Q16: How Innodb decided how many pages to flush at each checkpoint interval

HT: Usually it is 128, or less.

PZ: Looks like another magic number to experiment with.

Q17: How InnoBD handles blobs/text fields (needs more info)
According to the documentation, InnoDB put first 768 chars of each text/blob in the page and will allocate some space outside of the page.

However:
1. if the total size of the row is less than 8100 bytes InnoDB will not allocate additional space for blobs, even if each blob is larger than 768.
2. InnoDB will allocate additional space outside of the page for _each_ blob (if we have 8 blobs 8xN bytes will be allocated)

Question:
How much space InnoDB allocates for each blob outside of the page?

HT: For each column that InnoDB needs to store ‘externally’, it allocates
whole 16 kB pages. That will cause a lot of waste of space if the fields
are less that 16 kB.

The ‘zip’ source code tree by Marko has removed most of the 768 byte
local storage in the record. In that source code tree, InnoDB only needs
to store locally a prefix of an indexed column.

PZ: I think it is also very interesting question what happens for blobs larger than 16K - is exact size allocated or also segment based allocation is used.

Q18: Innodb Q: Is Group commit still busted in 5.0/5.1?

HT: Yes. However, work has been done on it by Inaam.

Q19: INNODB uses it’s own internal buffer pool but it’s in conflict with the Linux kernel’s buffer pool. In high load situations where INNODB is using most of the system’s memory the kernel can decide (incorrectly) to swap out MySQL. There are two solutions here. Memlock and O_DIRECT.

Memlock is apparently unstable on Linux. O_DIRECT is an alternative but Linus hates it. What are your suggestions here?

HT: According to tests by Peter Zaitsev, O_DIRECT works well to remove double buffering. In distant future, I would like to have the memlock also.

PZ: memlock already works - it is global MySQL Server option, though it may have problems on Linux if you lock very large portion of physical memory. There is also third alternative - “huge pages” which can be used for buffer pool and which are not swappable. They also allow to reduce number of TLB cache misses. huge pages along however do not stop IO pressure and OS may swap out not buffer pool but some other important parts of MySQL process.

Q20: We’ve migrated to using INNODB so that it operates 100% out of memory. This way every write is serial so that we can see the full write speed of the disk for throughput.

INNODB uses fuzzy checkpointing to commit data to disk. The problem that we’ve seen in high IO scenearios is that it commits too often and we’re only seeing 33% of the raw disk write speed. Since the commit isn’t perfectly serial it’s having to seek on disk which slows down throughput.

If we could control the checkpointing rate we could use an 8G write ahead log and tell innodb to do a full write of the database (basically dump memory to disk) once every minute or two.

This way we’d see a 3x performance boost and it would write at 100MBps vs 33MBps.

Any plans to enable tuning of the checkpointing rate? Postgres exposes this data and allows the user to tune the checkpointing values.

HT: Hmm… we could tune the way InnoDB does the buffer pool flush. I think Yasufumi Kinoshita talked at Users’ Conference 2007 about his patch that makes InnoDB’s flushes smoother and increase performance substantially.

I assume there is lots of room to tune the flushes, since I never optimized the algorithm under a realistic workload.

Making the doublewrite buffer bigger than 128 pages would require a bit more work. Now it is allocated permanently in the system tablespace when an InnoDB instance is created.

PZ: Sequential “dump” of buffer pool would need more optimizations to work - Innodb would also need also to write not-modified pages if this will get sequential write. Say if we have 1MB segment with all pages in buffer pool it well may be faster to do 1 write than flush 10 non sequential pages from it which were modified.

Q21: What’s the status of INNODB in 5.1.x?
Specifically: What’s the current status of innodb_thread_concurrency ? Is it suggested to set this value to a LARGE value (somewhat like 200) for additional throughput?

HT: ha_innodb.cc in 5.1:

static MYSQL_SYSVAR_ULONG(thread_concurrency, srv_thread_concurrency,   PLUGIN_VAR_RQCMDARG,
    "Helps in performance tuning in heavily concurrent environments. Sets the max\
    imum number of threads allowed inside InnoDB. Value 0 will disable the thread t\
    hrottling.", NULL, NULL, 8, 0, 1000, 0);

The default is 8, which will work well in most cases. If you are not seeing ‘thread thrashing’ (lots of threads waiting for semaphores in SHOW INNODB STATUS), you can try to disable thread throttling completely
by setting the value 0.

But if you see thread thrashing, then a value 1 or 2 often solves your thrashing problem.

PZ: Values 1,2 may solve your thrashing problem but also will limit innodb to be able to use only couple of CPUs efficiently. Thought even that is often better than bad thrashing.

Q22: Also, What’s the deal with group commit being broken in 5.1.x? Is it possible to get the same benefit if you’re performing INSERT with multiple values? We build up INSERTS on our clients and insert values 50 or so at a time.

HT: For most users, group commit being broken in 5.1 makes no difference. If you have a battery-backed disk controller cache, then the commit returns in less than 100 microseconds. And if you do not have, then the only way to get good performance is to set innodb_flush_log_at_trx_commit=2, that is, to flush the log to the disk only once per second.

PZ: We’ve helped number of users who had serve regressions in 5.0 because of group commit being broken. Most do not have RAID with BBU. With good RAID with BBU you can get 2000 fsync/sec or more which is typically enough.

Q23: Rumor has it that if you disable the new XA support (which we don’t use) then you’ll get group commit again.

HT: I do not think so. Sergei Golubchik serialized the MySQL binlog write and the InnoDB log flush with a mutex in 5.1, to implement XA, and switching off the XA will not remove that serialization. MySQL’s binlog and InnoDB’s log must have the transactions in the same order, for a recovery based on MySQL’s binlog to work.

Of course, if you remove that mutex from 5.1, then InnoDB’s group commit works again.

PZ: You can disable binary logging to get Group Commit back. Though this is often not the option. Here are some benchmarks we did.

Q24: INNODB has typically had problems scaling on multicore boxes. The new quad core CPUs from AMD and Intel means that 8-core boxes are going to be common place. We’re considering buying 40 8-core boxes with 32G of memory. Have any specific thoughts here? INNODB was originally written on single core CPUs.

HT: Users have reported lots of InnoDB scalability problems from multicore CPU’s. The most recent 5.0.xx behave better. We will continue the scaling improvements. Latest patches of Yasufumi Kinoshita attained very nice scaling up to 8 or 16 cores. These patches are not in the official InnoDB, though.

PZ: If your load is CPU bound and you’re scaling out you can get better performance by using couple of MySQL Servers on single node. You can make them to use different hard drives and bind to different CPUs.

Q25: In InnoDB, the referenced columns of a foreign key constraint need not form a primary key or a unique constraint: it is sufficient if the referenced columns form a consecutive set of leftmost columns of any index. Can you describe a real-world use case where it would be useful to have a foreign key not reference an entire primary key or unique constraint (something that is mandatory in every other RDBMS that suppors foreign key constraints)? Any concrete examples are appreciated.

HT: Yes, it is sufficient that a foreign key and the referenced key appear as the FIRST (leftmost) columns in an index, in the same order in the foreign key and the referenced key (this same order condition could be relaxed, though). The index is required for fast lookups: it can be used if the columns are the first columns in an index.

I think it is sound design practice to make the foreign key to reference an entire primary key, so that you can easily port your applications to other database brands. Maybe in some denormalized database (for example,
if ORDER and ORDERLINE tables are joined to form a single table), it might make sense for a foreign key to reference only a prefix of the primary key.

PZ: Thanks Heikki, Remember we’re waiting you to answer second portion of the questions.

---

Entry posted by peter | No comment

Add to: | | | |

以下是一篇IT评论，不喜欢看的可以现在就撤了。

一直有传闻说Yahoo投资新兴的社交网络Facebook。现在，传闻成为了事实，而且超越了事实。两家公司在周三公布消息说，微软将投资2.4亿美金换取Facebook1.6%的股份。请注意，二点四亿美金，只取得了1.6%的的股份（警告初高中同学，这种写数字的方法是在作文中是绝对禁止的，日期、数字要求统一，大写就大写到底，阿拉伯数字就阿到底，不可以混杂）。很多IT人很快地拿起了计算器，2点4亿除以1.6%。。。。。。Holy Shit！！！15，000，000，000美元！不用数了，是150亿！金山刚上市，市值也没有150亿人民币，人家那边还得乘以7点5呢。

不忙心痛，因为没有最痛，只有更痛。请看下面这一句：Mark Zuckerberg，这个年仅23岁，从哈佛退学的Facebook创始人拥有20%的股权，现在这些股权价值3，000，000，000亿美金。别数了，是30亿。他老娘生这么个儿子出来，23年就值30亿，每年增值1亿多美金，真是英雄母亲。23岁，30亿，听起来跟彩票新闻一样。你退学，别人也退学。别人23，你32。你歪脖二点零，别人也Web2.0。为什么结果会有那么大不同呢？

我相信，从周三到现在，很多IT人应该48小时都没有睡，辗转反侧，百抓挠心。IT世界依然在这个古老的星球迈进21世纪之后源源不断地创造奇迹，几时能轮到我们也插一腿呢？做为一个IT民工，我也陷入了深深的思索之中。由于思考得如此深入，以至于闹钟响了都醒不过来，在泛滥的口水中继续遨游，遨游。。。。。。

关于FaceBook的故事，本Blog的编辑、记者读者们，建议你们阅读一下译言的专题：《FaceBook 启示录》，然后你们就可以在财经或者娱乐版上报道这个消息。会有很多女读者问你们要Mark Zuckerberg的MSN的，相信我。

为什么我们不能插一腿？这个问题我也百思不得其解。李约瑟博士复生，恐怕他也不能给我讲明白里面的道理。我感觉中国的IT业很奇怪，比如说刚刚提到的译言，这是一个标准的Web2.0网站。创建者希望搭建一个语言平台，把英文世界中的好文章翻译为中文，提供给中国的网民。这样，中国的各大通讯社也就不用在国外养一大帮吃白饭的家伙，把老子的文章抄袭了都要算“摘编”。我觉得，这是一件功德无量的事情，也是一件极有意义的事情。这个国家有学许国璋英语的，有学张道真英语的，有学新概念英语的，有学疯狂英语的，任何一个破书店都有外文柜台，但是译言它他妈的就是不火。

一个网站，有内容，有实用，但是就是火不起来。我实在理解不了，只能用单位的打印机把译言的Logo打印出来，然后放在暖气片上烤，烤得外焦里嫩了，再用拖鞋抽：“你说你怎么就不火呢？怎么就不火呢？”房间里回荡着拖鞋青翠欲滴的响声，我听到在四壁的混响中有一个更洪亮的声音在回答：“你丫怎么不参与呢？你丫在干什么呢？”

我很忙，我要看新浪的社会新闻，看Sohu博客的光屁股美眉，玩QQ游戏给小人穿上衣服，打网游抢一套极品装备，找BT站点下一套AV新片。在中国的互联网上，可以做的事情很多，这些事情的价值加起来比零稍稍多那么一点点。从90年代开始，中国的互联网大概只有前5年是创新的五年，是有意思的五年。之后，随着网络的道德指数越来越高，创新能力也就越来越低。站长们都很忙，今天签一个自律公约，明天签一个文明办网协议，估计没时间做技术活。一个连Youtube、Flickr都访问不了的地方，还谈什么创新？现在FaceBook火了，不如直接封掉。那就可以当它不存在，我们依然可以在ALexa上满满意意看着前十名里有Sina，有Baidu。

以前说，要有多少中国人造多少双袜子才能换一辆美国汽车。现在我们也造汽车了，QQ，奔奔，那么，又需要多少汽车能换别人一个网站？为什么我们总是站在世界食物链的末端呢？为什么老要以自己是可以吃泥巴的小虾而自傲呢？李约瑟博士，你的那本大书里怎么没有说明中国在现代依然落后的根由呢？

为什么5460不能变成FaceBook呢？为什么校内网、第九公寓不能变成FaceBook呢？现在，FaceBook价值150亿美金。从下个月开始，大概又有一大批国产FaceBook要问世了。我也决定参与一下，花三万块钱买台服务器。500块钱雇两个计算机系的大学生当程序员，源程序照抄FaceBook。站名就叫FaceShu.com，找一帮IT评论和各门户网的IT编辑吹嘘一下。花十万块找十个美女帖大头照，最好一丝不挂，上来就写“急征一夜情”或者是性爱日记。麦田说，一个成功的网站后面必然站着一个女人。我站十个，而且还是光的。再砸两万买流量，全国的弹窗广告一夜全换上我的。几百万台计算机全部安上木马，一上线就狂刷Alexa工具条，把排名刷到全球前一千。这时候就可以收获了，那边侃着风险投资商，这边把弹窗、彩信、短信统统加上。叫会计做好现金流量表，随时准备在成本价后面加四个零卖给下家。

不就是这样么？还能是怎样？在这里，我做为一个网民，找不到多少为网民服务的网站，找不到多少提供有价值服务的网站。世界上最多人数的网民，生活在一个价值极低的网络世界里，这就是现实。在这里，复制比创新有前途，开垃圾站比开好站赚钱，这就是现状。在世界最大的局域网里，我觉得自己幸福得像一头猪，如果没有FaceBook这种事情烦扰我的话。

发表者：Google（谷歌）研究员 吴军

1. 时势造英雄

2. 英特尔摩托罗拉之战

资金密集型的日本半导体公司终究不可能是技术密集型的英特尔公司的对手。英特尔公司迄今唯一遇到的重量级对手只有八十年代的摩托罗拉。正如同罗马帝国的崛起是通过在布匿战争中打败原有的霸主迦太基而完成的，英特尔的崛起是靠击败老牌半导体公司摩托罗拉而实现的。摩托罗拉成立于 1928 年，早在二战期间，它就是美军无线通信的供应商。从六十年代起，它在通信和集成电路方面领先于世界。摩托罗拉比英特尔早两年推出在小数运算性能上五倍好于 8086 的 16 位微处理器 68000。68000 这个名字是以它集成的晶体管数目六万八千个而获得的。而 8086 只有不到三万个晶体管。当时，不少工作站包括惠普、太阳和已经不存在的阿波罗等等都采用的是摩托罗拉的处理器。在英特尔搞出 80286 的同一年（1982 年），摩托罗拉推出了在性能上明显好于 80286 的 68010，继续作为当时主要工作站的处理器。据说英特尔为了和摩托罗拉竞争在型号上耍了个小花招，英特尔公司第二代处理器本来应该命名为 80186，但是英特尔将这个编号留给了一个不重要的输入输出处理芯片，而将它的系列处理器的编号一下跳到 80286，不懂技术的人还以为英特尔的处理器比摩托罗拉高一代。在 32 位微处理器的较量中，摩托罗拉在技术上和推出的时间上完全占了上风，它接下来的 68020 明显好于英特尔的 80386，除了被用于主要的工作站上，68020 还并被苹果选为麦金托什的处理器。

这时，英特尔公司从外部得到了强援。由于 IBM PC 兼容机的逐步普及，技术上相对落后的英特尔反而占了更多的市场份额。虽然，摩托罗拉后来又推出了对应于英特尔 80486 的 68030，但是，这时各个工作站公司都开始开发自己减指指令（RISC)的处理器，摩托罗拉只剩下苹果一个用户便很难和英特尔竞争了。几年后，摩托罗拉干脆自己也加入了 RISC 的行列做起 PowerPC，十年后，随着苹果也开始使用英特尔的处理器，摩托罗拉彻底推出了微机处理器市场。

摩托罗拉并没有败在技术和资金上，八十年代以前，摩托罗拉在资金、技术各方面都明显强于英特尔。在很长时间里，它的处理器从性能上讲要优于英特尔的同类产品。摩托罗拉之败，首先是外界微软的因素，即英特尔有了微软这个没有签约的同盟军。但是，摩托罗拉自己在商业、管理和市场诸方面也有很多失误。如果摩托罗拉自己经营得当，它今天应该能通过精简指令集的处理器守住工作站和苹果的市场。

要分析摩托罗拉之败，我们不妨来比较一下英特尔和摩托罗拉这两个公司。首先，这是两个不同时代的公司。总部在美国中部伊利诺斯州的摩托罗拉虽然也是一个高技术公司，也经历了八十年代的信息革命，但是它的作态完全还是五六十年代的传统的公司。虽然摩托罗拉对雇员在工资和福利上待遇不错，但是公司和员工，基本上还是传统的雇佣关系，公司内部管理层次较多，大部分员工基本上没有多少股票期权。因此，公司的业绩和员工的利益关系不大。英特尔公司则是一的典型的硅谷公司。每个员工的工作强度比摩托罗拉要大很多，但是每个人平均的股票期权也多很多。硅谷几个比较好的学区的房子，不少被英特尔公司的早期员工买走了，而这些房子靠工资是一辈子也买不起的。几年前，美国历史频道（History Channel）在节目中评论了中日甲午战争。美国的历史学家认为，这是两个不同时代军队之间的战争，虽然双方武器相差不多，战争的结果不会有任何悬念，因为一个在专制的农业时代后期的军队很难打赢一个兴起的工业化国家的军队。英特尔和摩托罗拉之间的竞争也是如此。

第二，两个公司的统帅水平相去甚远。英特尔公司八九十年代的 CEO 格罗夫虽然是学者出身，同时也是微机时代最优秀的领导者和管理者，他几次被评为世界上最好的 CEO。摩托罗拉公司由加尔文（Galvin）兄弟创办，公司六十年代传到了儿子手里，八九十年代传到了孙子手里，是个典型的家族公司。俗话说富不过三代，这话果然应验在加尔文家族上，三代人可以说是一代不如一代。孙子辈的克里斯托弗•加尔文虽然是被"选成"CEO的,但是如果他不姓加尔文，他永远不可能是摩托罗拉的 CEO，甚至进不了工业界的高层。

在业务上，半导体只是摩托罗拉的一个部门，而微机处理器又只是其半导体部门的一项业务，可是它对于英特尔来讲却是全部。因此，摩托罗拉即使完全退出微机处理器市场也不过是损失一些地盘，而英特尔一旦失败，则会面临灭顶之灾。一般来讲，华尔街总是希望一个上市公司有尽可能多的而不是单一的收入来源，摩托罗拉确实是这么做的，它曾经在计算机的处理器、通信的数字信号处理器、对讲机、BP 机、手机和电视接收器等很多领域发展。结果每个领域都很难做大。英特尔公司做事情非常专注，直到今天，它一直集中精力于个人微机的处理器上。每一代产品的研发都是集中大量的人力和资金，每一次都是只能成功不能失败。这就像一把散线和一股绳，一把散线很容易被一股绳扯断。因此，专注的英特尔最终把计算机处理器的业务做得很大、很好，而业务多元化的摩托罗拉最后除了在微机处理器上败给了英特尔，在手机上碰到了诺基亚，在信号处理器（DSP）上又败给了德州仪器（TI）。很多人问我雅虎有没有可能在搜索领域赶上谷歌，我明确地回答--没有，因为雅虎不可能专注在这个领域。有时，一个好的公司不能完全按华尔街的意愿办事。

如果时光可以倒流，让摩托罗拉和英特尔当时换个个儿，即 IBM PC 采用摩托罗拉的处理器，而将服务器厂家和苹果交给英特尔。那么二十年发展下来，摩托罗拉也很难成为半导体领域的老大，因为它内部的问题没法解决。

dbanotes posted a photo:

christophe.varoqui.free.fr/graphics/macroflux.png

• Oracle OpenWorld News Aggregator
  Read and monitor Oracle OpenWorld related blogs and news sources, all in one place.
• Oracle OpenWorld Video Casts on YouTube
  Daily videocasts from Oracle OpenWorld 2007 - “official” as well as nonofficial.
• Oracle, MySQL and PostgreSQL feature comparison
  Differences in their handling of complex SQL and optimizing choices.
• Find sequence gaps using Oracle’s analytic functions
  Oracle’s analytic functions provide a much cleaner way to do gap checking. These allow you to see the value in an upcoming row (LEAD) or previous row (LAG), while still using the full set-oriented processing of SQL.
• Technical Papers: Oracle and SQL Server
  White papers covering a wide range of topics, including performance optimization of Oracle and MS SQL Server, RAID, SAN, and Linux configuration.
• Data Modeling 101
  Overview of fundamental data modeling skills that all developers should have.

More from my bookmarks on del.icio.us

---
Related Articles at Eddie Awad's Blog:

• 5 Useful Links You Should Check Out Today (2007-10-05)
• 5 Useful Links You Should Check Out Today (2007-09-28)
• 10 Useful Links You Should Check Out Today (2007-09-07)
• 40+ Links for Knowing the New Oracle Database 11g
• LOBs Gotcha in ColdFusion