MySQL 存储引擎实战

先大概介绍一下系统的情况，每天的insert ，delete，update 的操作差不多在5亿左右，然后select的表的大小最最大的在5亿和5000万左右。那么我们就通过我的实际血泪史来看看mysql的存储引擎的区别吧。

系统一开始在线上模拟测试的时候，因为我的不小心，把engine设置成为了myisam引擎。在实际的模拟测试的过程中，发现任务队列堆积非常严重。后来OP帮忙一查，发现原来是错用了存储引擎，myisam的存储引擎对于写的操作是表锁。这样导致我们大量对数据库写的操作被pending住了，汗。

立马把数据库引擎换成了innodb，innodb的写操作是行锁，写的效率比myisam要高很多，但是相对应的其读的速度肯定要比myisam低了，因为它是用的Btree的索引。但是我们又发现了一个问题。我们每天的insert操作是一个定时的任务，差不多在1亿5千万左右，差不多高峰时候每秒的insert有1万个左右。我们发现磁盘IO完全成为了瓶颈，磁盘的使用率在100%左右徘徊。而且还导致了系统load升高，升值导致db挂了。可是这个怎么办呢，innodb是目前我们的最佳选择？

写磁盘是innodb不可避免的，团队开始考虑迁移到内存数据库。可以那种key－value值对类型的数据库对于我们当前的业务不太适合。而且我们也没有那么多时间去重写底层的系统。DBA提出用memory的存储引擎。memory是内存数据库存储引擎，所以的数据存储在内存里面，一旦重启数据库就数据全没了。不过我们的系统对于数据的持久性要求不高。不过问题是我们的数据量大，所有我们迁移到了一台72G内存的数据库上面。不过我们只是把一部分的表变成了memory引擎，还有一部分还是innodb的引擎。

上线后的第一个周末，又出问题了，innodb的磁盘扛不住了。我们一看，汗，怎么还是一个sata的硬盘，起码数据库服务器好歹也是一个sas硬盘+raid的配置啊。哎 ，我们就顾着内存大，忽视了磁盘。没把发，把所有的表都换成memory，总算系统是稳定的，低load的跑了下来。