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

      存储引擎

　　继续上一篇的讨论，记录针对 MySQL 在大企业级商用上我的一些零星想法。网络上到处都有关于各个引擎之间的对比。这里要提醒一点是，注意各个引擎的锁的粒度。InnoDB 是行锁，锁的实现是依赖于索引的，MyISAM 只是表锁。锁粒度是衡量存储引擎的一个重要指标，其能力很大程度上决定并发能力。

　　至于 TRANSACTION ISOLATION LEVEL，则是另外一个需要衡量的指标。

　　老生常谈的，某某引擎适合什么类型的应用，归根结底还是由于其实现的机制决定了引擎的特性。

　　存储层的解决方案

　　相信没有人愿意在 MySQL 上用 RAW 设备，很多人几乎就是直接把数据文件放在文件系统上(个人认为，对于数据库这样的应用来说，文件系统可靠性还有所欠缺)。我还没发现 MySQL 上类似 Oracle ASM 的解决方案。如果用文件系统，单节点的数据存储能力肯定要受到制约--没有人喜欢把几个 T 的数据扔到一个 MySQL DB 上吧? 一旦某个文件系统故障，麻烦就来了。从这个角度考虑，或许 LVM2 是一个可选的方式。

　　当然，如果把数据文件扔到 SAN 上也还不错。一方面问题是，现在存储厂商对于 MySQL 的重视长度还远不如 Oracle、DB2 等老牌商业数据库。另一方面，很多 MySQL 用户没有 SAN 环境的，数据都是在本地磁盘上。

　　固态硬盘与 MySQL

　　前两天有朋友在上一篇分析留言，提及应注重闪存的应用。其实还不如布署固态硬盘 (SSD) 对 MySQL 可能的影响问题。 相信现在有很多企业需要在 DB 的 IOPS 上寻求突破，SSD 是个可能的突破口，但从目前我收集到的数据来看，还没有足够的数据说明启用了 SSD 的 MySQL 能有预期的数量级上的 IOPS 提升。

　　商业支持

　　现在 MySQL 的背后有 Sun ，但是，如果不购买服务的话，到哪里去找比较正规的商业支持(我是说软件集成商)? 即使购买了服务，如果问题出在存储引擎上，MySQL 能给即时、有效的技术响应么? 这也是 MySQL 没有自有存储引擎的一个弱点，因为衔接的环节多，一旦有商务上的问题，很容易陷入扯皮阶段。

　　这是这个系列第二篇。如果有第三篇，我倒是想写几点关于 MySQL 的设想。