有过 MySQL 使用经验的人应该知道，MySQL 要想在线修改个 Schema 结构是个麻烦事，规模不大的表增加个索引造成的锁也可能导致整个 Web 应用宕机。这一点没办法和 Oracle RDBMS 、DB2 等商业数据库相比，甚至 PostgreSQL 也具备联机 DML DDL 的能力。我在过去写过一系列并不成熟的《MySQL 大企业级应用可行性分析》 文章中，也很是担忧这个问题。有些公司想迁移到 MySQL ，也因此而只能采取保守的做法。
不过现在这个缺陷临近被彻底修复。Facebook 的数据库技术团队将 Online Schema Change （OSC) 的代码开源，并且撰文进行了详尽的阐述。这是个很大的技术革新，Facebook 数千台 MySQL 服务器在过去增加个索引需要几个月的滚动升级，现在只需要几天即可。
MySQL 5.1 的 InnoDB 引擎具备 Fast Index Creation 的功能，在创建索引的时候无需复制整个表的内容，但是对于一定规模的大表增加索引，仍然需要花费大量时间，对于在线应用来说，仍然不可忍受。而 Facebook 的 OSC 则进一步进行了改进。对于 MySQL DBA 来说，这是个福音。感谢 Facebook 的员工 Vamsi Ponnekanti 的工作。如果要我说，年度 MySQL DBA 应该授予给他。当然，Online Schema Change 的部分代码从 Shlomi Noach 的 Openark Kit 中派生，建议 Shlomi Noach 一同获奖…
对于 MySQL 来说，我认为这是个里程碑式的时刻，无论 Oracle 将给与 MySQL 多大的投入，其它公司已经主动拿过接力棒。Facebook 技术团队再次立功了！
–EOF–
Update: Facebook 工程师在帖子里说了”Note that the above operations can be done within the storage engine itself, or using an external (PHP) script.” 要知道，这并非只是一个 PHP 脚本的实现。我建议技术人员看帖子应该更仔细一些。也不要说这东西你早都想到了之类的技术阿Q的话，我倒现在为止没听到国内一个公司的技术人员做出来这东西。从想法到实现，其实还有十万八千零一公里呢。
当大家还在关注MySQL5.5.6RC版本的时候，OSC却改变了MySQL的历史！
看起来只是一个php工具程序？不是对mysql的代码更新？
Come on，man.
这只是利用trigger实现了一个在线的索引添加，所有这些都和openarkkit的思路一样。我曾经还通过trigger实现过类似Oralce的物化视图，其实思路也是大同小异，这很强吗？我觉得一个Level高点的DBA都应该可以想到，这不是一件难事，更没有理由这么激动。
我觉得要在代码底层让MySQL实现在线索引的添加这才是最重要的，我相信OCS只是一个不错的解决方案，仅此而已。但是他同样会带来一些问题，只是现在或者使用者还没遇到而已。
中国很多的MySQL DBA都是停留在应用的角度，的确，从Oracle，SQL Server的DBA过来来看，他们只能机械应用，最多只是比人多知道一些RAC的一些Bug，除此之外他们没有任何的创新。可能是Oracle都帮他们完成了。另一方面来说，DBA大多没有掌握好一些底层的编程经验，有Java的经验是可以对应用有很好的理解和掌控，可是对于数据库底层的了解没有任何帮助。而Facebook比较有意思的是，你发现他们有1800台数据库，确只有2个DBA。这才是Facebook，Google不同于国内对于MySQL的应用。
而开源的魅力不仅仅在于他是免费的，更重要的是创新。即使淘宝，阿里巴巴他们在MySQL方面也毫无建树。是的，我听说他们在尝试修改底层了，但是他们的目的只是为了证明他们可以修改，而不是在于创新，他们所做的事情都是在模仿前人做过的事情。而放眼整个中国的MySQL应用，我只看到InnoDB Secondary Buffer Pool的patch。我没尝试过，但是那的确是个不错的创新思想。
让我不知道说什么好：
Note that the above operations can be done within the storage engine itself, or using an external (PHP) script.
仔细看看Facebook的帖子再来说吧
这只是个php工具，一毛钱都不值
Note that the above operations can be done within the storage engine itself, or using an external (PHP) script. We followed the latter approach as it can be implemented much faster.
Facebook team 认为第二种PHP的方式更快捷的实现，所以只实现了PHP版本。
值不值，不在于这个php脚本本身，在于它是否完善了某些功能，真的提升了效率。看待问题永远不要停留在表面，我们需要学习的是他们这种创新的能力以及解决问题的方法和勇于实践的精神。
还有一种方法也可以达到在线修改表结果的目的，方法是在Slave上修改表结果，等同步后切换到Slave上去，我们更喜欢用这种方式。当年Openark Kit的实现我们分析后总感觉心里不太有底，首先正确性验证挺复杂的，另外只支持InnoDB，还有就是对系统的性能影响会受应用模式等一些因素影响，若不是高手操作容易搞出问题。
我们更喜欢用借助于slave的方式，不只可以加索引，加字段也行，我觉得这种方法大家也可以考虑
据我说知，这个有公司实现过的，是java版的
从想法到实现，其实还有十万八千零一公里呢
==========================================
嗯，注重实际的操作或者实现是很重要的
Peter说的—-而放眼整个中国的MySQL应用，我只看到InnoDB Secondary Buffer Pool的patch。我没尝试过，但是那的确是个不错的创新思想————-我第一次看到这个patch的时候就很惊讶，将oracle的extradata的思想借鉴过来，就算很多人想到，但是有多少人去用自己的代码去实现，然后再优化呢？
http://bbs.chinaunix.net/thread-1768552-1-1.html
“甚至 PostgreSQL 也具备联机 DML 的能力”
应该是“也具备联机 DDL 的能力”吧？
是的，我写错了。多谢指正！
更正一下。
实际提高了生产效率，就是有价值。
事实胜于雄辩，少说多做才是王道。
这确实是一个php的实现，乍一看原理也不复杂，但如果没有对MySQL的非常深入的了解，是很难完成的。
很多人也许就满足于知道一知半解的原理而浅尝辄止。
percona公司的pt-online-schema-change的perl程序，触发器写的也很巧妙。