作者文章: Fenng

MySQL 大企业级应用可行性分析(之一)

前两天在上海参加技术研讨，讨论了关于 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 的策略对数据进行切分，所以，分区的问题倒似乎并不是最为关键的。

因为是整理思路，这算是这个系列的第一篇。

Discuz! 优化的误区

很多 Discuz! 的用户在论坛规模达到一定程度上，就要经常性的考虑优化的问题。现在网络上的很多热心的技术人都分享了 Discuz! 的优化经验，应该说，很多经验还是不错的，但也有的帖子可能会让用户走入误区。

误区一：SQL 慢，加索引

多数情况下，数据库可能是瓶颈。通过 Slow Query Log 发现执行时间比较长的 SQL 并不难，于是有的人一看 SQL 走了全表扫描，干脆添加个索引好了。

其实这个地方值得商榷的。第一，必须确定一下该 SQL 执行次数到底是怎样的? 执行真的很频繁? 那么对应的页面是否通过 Cache 可以减少对 DB 的冲击? 如果可以，尽量不要添加索引，索引本身对表的负面影响也是很大的，比如降低更新速度，影响并发能力等。

误区二：瓶颈一定在数据库上

前面说，数据库”可能”是瓶颈，但不总是瓶颈，优化的第一步，必需要有针对瓶颈优化。很多时候，图片访问带来的压力甚至比数据库压力还大 — 有的用户数据库、用户上传的图片文件、Web 服务器都扔到一台服务器上，这时候，第一手去调整 MySQL 或许会有作用，但价值不大。

应该说，瓶颈的有效定位的确是个技术活儿，对于一个新的论坛环境，也有人用逐一尝试法来做，这倒也没什么。

误区四：盲目的静态编译 MySQL

静态编译 MySQL 有好处，但如果系统已经在线上运行了，在原有环境中进行静态编译未必能带来多大好处。我问过一些朋友，静态编译到底带来多大好处? 没有几个人能说清楚。

对于 PHP 也是这样，如果一次优化从其它方式上能带来更清晰、直接的开销，就不要重新编译

误区五：反复尝试，但不建立基准数据

这其实是第四点的延伸。而建立基准数据，实在应该是优化的最基本的步骤。这样才能有效的评估优化的效果。否则的话，象误区一描述的，添加了一个索引，短期内可能感觉快了，长期看，性能可能又会慢下来。

误区六：一次进行多个优化步骤

这可能是比较普遍的”习惯”了，有的朋友喜欢一次调整多个参数或是多个环境的设置，然后观察效果。如果每个步骤都是”对”的话，那么效果看起来是好的。如果有的步骤调节”错”的话，可能会抵消那些有效果的优化步骤。

优化策略是个见仁见智的问题。以上只是个人浅见，欢迎留言探讨。

–EOF–

谨慎对待自我生成内容(egc)

标题里的 egc 代表：ego-Generated Content，是我模仿 UGC(User-generated content)造出来的一个词。用以表示个人生成内容，尤其是在一些 UGC 网站产生的内容。

记得 CSDN 的曾登高问过我：

如果 CSDN 开发一个 Google Group的功能，你会创建自己的小组，建立一个兴趣小圈子吗?

我的直接回答是”不用”，尤其是国内的很多明显是克隆国外服务的站点，比如饭否这样的。最近一段时间里，一觉醒来，似乎遍地都是 SNS ，对于一些明显是浑水摸鱼的服务，我一般会敬而远之，即使注册了，也基本不会真的花费心思去参与。原因只有一个：自己生成的内容是有价值的，有价值的东西不要随便扔到不靠谱的地方，当然，这么说肯定会引起一部分人的误解(我现在也在用个别的 SNS 服务，主要的目的还是为了研究用户体验和产品设计。作为一个技术人员，至少到到现在为止，还没从 SNS 服务里面发现比较有价值的技术内容)。

自我生成内容成本其实很高。考虑到每个人的一生也就那么长的时间，如果你的时间有价值，那么产生的哪怕每个字符都有必要保存，一旦内容丢失，对个人来说，就是最大的浪费。我个人不认为 SNS 之类的服务能产生更有价值的信息，倒是有可能产生更有价值的”关系“，而且，SNS 的服务很少让人静下新来作一些”沉淀”，每天被新信息充斥着。

至于 LifeSteam：之所以会产生 Lifestream 功能的服务，其终极目的还是要把一个人产生的内容融合起来，但这里面最大的一个问题是，不能做信息的归档保存(类似数据库-> 数据仓库的机制)，只是即时更新的信息流而已。从这一上来说，也不利于 egc 的整理。

所以，有必要谨慎对待自我产生的内容，尽管你还没发现这些内容的价值。也不要趋之若鹜的去到处尝试一些新服务，做小白鼠其实没什么大价值。

个人建议：

同类服务只用一个，最多用两个，如果用了三个，那么你是一个义务测试员。

–EOF–

《赤壁》–战争片中的喜剧片

周日上午在上海，宾馆里的电视放着在成都举办的电影《赤壁》首映礼，听着到场明星如潮的谄评，我开玩笑说，”没准是个大烂片”，没错，说中了。

有《三国志》也没用

和《三国演义》不相符的地方，吴宇森可以说是研究《三国志》得来的，和《三国志》不一样的，可以说是遵循《三国演义》。可几个人面对着一匹难产的马折腾了半天，这是跟什么地方学来的? 《英雄本色》么? 这样多余的段落实在太多了，听牧童吹笛、孙权射老虎(这段是给外国人看的，建议海外版把这一段加进去，很弗洛伊德）、古代足球–蹴鞠等完全是可有可无的桥段，没有这些，冲着当年吴宇森拍过的片子，大部分观众可能也愿意掏钱的。

人物形象

冷兵器变成了现代武打，下次让关羽骑马吧，每次跑着出来(当然是穿着刘备给打的草鞋)，拖着大片刀也的确不太好；张飞也最好带着兵器，别总赤手空拳，好像把丈八蛇矛弄丢了似的，这样不好! 至于小乔，那双手也太大了些，特写太多了些；周瑜的头盔实在有些不好看，建议和《投名状》学一下嘛，反正都是古装，穿越一下就成了。至于瑜亮的大段飈琴，简直是现代摇滚青年的翻版嘛。

吹毛求疵

刘备自称的”豫州”也实在让人倒胃口，哪有这么说的? 而八卦阵那一段，估计连外国人也糊弄不了吧? 孙子兵法都说了，”十则围之”，对付区区两千敌军还折腾半天。

那些笑声

搞笑的亮点有很多：刘备要诸葛亮多吃米饭，刘备重拾本行打草鞋，诸葛亮在孙权殿前走起的模特步，关羽给孩子们上课居然说出”现在读书，以后就会有饭吃”，而张飞聚精会神练习书法(尽管张飞历史上的确是书法家，可剧中人物那握笔的姿势实在有些问题嘛)，听着一次又一次的笑声，完全有理由相信这是吴导演的转型喜剧之作。

估计很多人会疑问，这就是那个拍出《英雄本色》的吴宇森么? 现在开始怀念那“一亿颗子弹”吧，然后，面对着下集可能出现更多的恶评，吴导演最需要的是”冷静”。

–EOF–

比较出彩的地方，应该算曹操的 “架六龙，乘风而行；九合诸侯，一匡天下” 那个镜头。这句话是从曹操的两首诗里面拼出来的。