前两天在上海参加技术研讨，讨论了关于 MySQL 的一些面向企业级应用的思路，今天和几位同事开会，也谈及了能否用 MySQL 替代当前 Oracle 的问题。干脆整理一下思路，算是做个备忘。
首先说明一点的是，我不是说 MySQL 没有大企业级的应用，事实上，可以看到越来越多的成功布署 MySQL 的应用，但是，还不够多，还有许多大企业的关键应用还不敢用 MySQL。或许这篇小文能和大家一起探讨一些比较”虚”的东西。
存储引擎
由于 MySQL 自己一直没有一个成熟可靠的存储引擎，估计这让他们深感痛处(尤其是目前最成熟的事务型引擎 InnoDB 又在 Oracle 手里)。MySQL 寄予厚望的 Falcon 在开发了两年多之后，建树不大，而该项目带头人 Jim Starkey 前不久又离开了 MySQL，陋屋偏逢连夜雨。
Sun 会给 MySQL 一个稳健的引擎么? 我看短时间内未必能达到。除非，Sun 从 Oracle 手里把 InnoDB 买回来。
如果进行大企业级应用，考虑到引擎本身的稳定性，似乎可选的也只有 InnoDB 了，但 InnoDB 的备份工具又是收费的。至于 MyISAM ，尽管有人的确喜欢用，但对于并发能力要求稍微严格一点，MyISAM 根本不行。
在线 DDL 锁表问题
MySQL 中，在线对表对象做 DDL 操作是要锁表的，对于可用性要求比较高，而应用变化又比较频繁的环境，这是个非常很糟糕瓶颈。没想到有什么好的办法，除非，像大家开玩笑说的，把所有的表都预留出足够的空闲列，减少类似增加列的变更麻烦。
这个 MySQL 天生的缺陷在 PostgreSQL 中是不存在的，比如创建索引，可以用CREATE INDEX CONCURRENTLY 的方式来减小影响。(MySQL 后续的版本中在逐渐改善这个问题：添加了 ONLINE 关键字)
这个看似是个小问题，但实际上却是对很多人最为困扰的。
在线备份问题
谢天谢地，MySQL 6.0 后终于具备在线备份的能力了。但现在，恐怕比较激进的用户也只能用版本 5 而已。
很多 MySQL 资深用户能够根据自己应用的特点布署适合自己的备份方式(尽管可能也会有缺陷，比如基于时间点的恢复)。
至于另一个常用来衡量 DB 可扩展性的特性：分区，现在 MySQL 已经能够支持了，尽管实现的的确有点晚。而使用 MySQL 的用户，一般都采取 Sharding 的策略对数据进行切分，所以，分区的问题倒似乎并不是最为关键的。
因为是整理思路，这算是这个系列的第一篇。
Feng对Mysql也颇有研究啊~
今天看了看zmanda，对于备份、恢复解决的比想像好的多。
前辈，总算提到 postgresql 了！
请问一下前辈，您对 postgresql 作为 web server 的后端怎么看？小弟对数据库是门外汉，但很想了解一下，苦无门径，希望指点，谢谢
mysql 5.1+innodb plugin下，创建secondary index会非常快，不像以前那样，还要重建整个表了。但也会锁表 :(
mysql备份可以采用lvm，或者启用复制后，在slave上进行备份，问题也不是那么严重的。
“陋屋偏逢连夜雨”简陋的房屋不代表防不住连夜雨，
原诗为：
屋漏偏逢连夜雨，
船迟又遇打头风。
期待后续的分析！
@ddh
如果对 POSTgresql 熟悉，那么用之也无妨
@zmanda
对于备份，还是希望 MySQL 自己能有个完善的解决方案。
其实Sun 重金收购了 MySQL AB. 多掏点钱收购 Zmanda 似乎也是个好办法
如果进行大企业级应用，考虑到引擎本身的稳定性，似乎可选的也只有 InnoDB 了，但 InnoDB 的备份工具又是收费的。
呵呵，oracle不收费吗？
分析的很是有理
@Fenng: 现在 MySQL 自己是没存储引擎，
那要是把 BerkleyDB 引擎加回来又如何呢？
我觉得当考虑大规模部署时，MySQL未必要复制Oracle等商用数据库的做法，应该综合考虑内存和闪存大量使用带来的影响。
http://www.infoq.com/cn/news/2008/07/ram-is-disk
假如那个是趋势，在分布式系统中，如果能把每个节点的内存和闪存容量充分利用起来，其随机读写能力极其惊人，索引甚至可能全部从硬盘中移出来，存储引擎应该针对这种情形优化。
MySQL应该抓高、低两端，把中端留给商用数据库。互联网上真正的高端应用(如Ebay/Amazon)反而降低了对数据库服务器功能的需求
既然提到了pgsql，那可以把为什么最终将mysql当作候选对象而不用pgsql的前因后果列文说一下吗
老大的文章很好！
好早的文章啊！哎 MySQL呀。