【原创】选择InnoDB还是MYISAM？数据库lock进程的困扰

最近碰到网站高峰期,在优化数据库上想方设法了.单服务器130万PV的话，还是可以承受的。前阵子数据库经验会出现locked进程，造成mysql卡死，继而网站出现短暂的假死现象，经过优化后，有所改善。但是提升还是有限的，估计在200万PV依然会出现瓶颈。现在使用dz的程序，discuz7.2没有支持memcache之类的东西来缓解数据库压力，要去全面改造的话，工程还是蛮大的，问题集中在缓存的及时更新上。所以在寻求一个更好的方案，等DzX1.5稳定后还是希望能够尽快升级到dzX，这个版本在性能上的改进尤其在支持memcache上。dz论坛经过很多年的实践经验上，负载压力还是非常好的，瓶颈在于session表，session存在表中，解决了多应用的登录问题，但是对数据库的性能是一个挑战，大家都知道这个表不断的再刷新变动。再数据库碰到LOCK的进程卡死的时候，也会发现很多session表的影子。


在网上，谈论选择InnoDB还是MYISAM上，多数的经验告诉我们，当读大于写，读多写少的时候，我们需要用MYISAM，这通常是正确的做法。经过分析，实际上影响性能的是update语句，在update的时候，才是百分百锁表。insert语句可以通过优化concurrent_insert=2来解决，再定期的做碎片优化。Myisam是支持insert与select并发执行的。在MYISAM优化的方案上，对于update造成了大量的lock进程，那么优化的时候采取low-priority-updates=1 降低update的优先级别。但是Myisam是极其容易崩溃的，崩溃产生的后果需要评估，如果对数据的完整性要求不高的应用，还是能够允许这么做的。其次使用myisam_use_mmap也是可以提供一些性能的。另外一个优化方案就是打下google的TCmalloc的补丁，这个补丁是极大的提高了内存的分配效率，使用多核服务器尤其重要。
         读取上，MyIsam是缓存索引的，在优化上影响性能的就是key_buffer_size 的大小，这个值的大小可以通过 show global status查询 key_buffer的use情况来定大小，一般总是小于key文件*.MYI的总和。
         那么到底用不用innoDB？那就看上面的优化方案能否解决问题，解决不了就需要分析了。实际运用中需要看实际情况，就discuz论坛来说，读肯定是远远大于写的，再加上一个uchome，还是读远大于写，但是问题就在于写的绝对数量上，尤其是uchome这类sns的应用，update的操作也是非常频繁的，还有ucenter和各个应用之间的通信，经常会发现在ucenter后台的通知常常会积累很多。通过在mysql中查询show global status like ‘%lock%’观察Table_locks_waited 的刷新频率，如果这个数字很大，并且不断的上升，那么需要考虑使用InnoDB了。MYsql5.5将innoDB作为默认的引擎，而且性能上有了10倍多的提升，这都是使用innoDB的理由。 当然由于discuz目前没有针对InnoDB做特别的优化，所以不能使用事务延迟写入，也不能发挥innoDB最大的性能，但是bbs的写入对于innoDB那是绰绰有余的了，而且在数据完整性安全性上都有了大大的提高。 除非select count (*) from 的语句占据了大部分的查询，否则选择InnoDB都是不错的选择。JAVAEYE的robbin将论坛的数据库改为innoDB后，发现并发性能大大的提高，我也觉得应该改改了。这次升级dz时候决定做一把了，如有体会心得，必定写出来分享。

原文地址
http://www.bugx.org/155

这帖子居然没人看。。。。