随机IO几乎是令所有DBA谈虎色变的一个问题，这个问题，往往在数据量小的时候不出现，在数据量超过内存大小时，才陡然出现，令没有经验的DBA促不及防，也令有经验的DBA寝食难安。

　　传统的数据库架构对随机IO几乎没有还手之力。传统数据库的核心通常是页级缓存、B+树、堆或索引组织表，这些机制，对随机IO的抵抗能力，都无一例外的可 悲的差。页级缓存有很强的“连坐”效应，就是为了要缓存一条有价值的记录，顺带可能要同时缓存百条无价值的记录。传统上这一点自豪的称之为 locality，是用来减少IO的，但往往会导致内存缓存的利用率很差。在记录的级别，应用的访问模式通常符合Zipf分布，其中10%的记录所占的访 问概率超过90%。如果我们用记录级的缓存，用相当于数据量10%的内存，就可以消除90%的IO，但用页级缓存，这10%的热点记录，很可能就分布在 70%的页面上，这样同样10%的内存，很可能只能消除可悲的30%的IO。B+树的情况也好不了，如果索引大于内存量，每次随机的索引搜索、插入和删 除，几乎都将带来一次随机IO（假设索引的非叶节点都在内存中）。

　　新的SSD硬件可以缓解随机读问题，但对随机写依然是无能为力。SSD的技术比较成熟了，期望它哪一天能魔术般的也搞定随机写，是不现实的。但我们可以从数据库架构上来想办法，谢天谢地，其实有很多办法，虽然未必能马上就用上。

　　先说记录的随机IO。之前已经说过，用记录级的缓存是很好的，我们NTSE的测试 表 明这一招很有效。但似乎不太有公开的数据库支持类似的功能。煺而求其次，大家可以用Memcached，但两者有重大区别。用Memcached时，很难 保证Memcached与数据库的一致性，除非用数据库事务来保证，但这样会导致在两个系统之间进行每个事务毫秒级的锁定。虽然数据库内置的记录级缓存也 需要用某种加锁机制来保证一致性，但这个锁定时间是微秒级的，并发度不可同日而语。但最重要的一点是，Memcached通常只能消除随机读IO，对随机 写无能为力。而数据库内置的记录级缓存，则可以很好的解决这个问题。数据库内置记录缓存的设计，常用的有几招：

　　1、最基本的一招是，如果要访问的 记录在记录缓存中，就不去读底层的堆文件。当然这是废话，如果不这样，那还叫记录级缓存吗？但如果仅仅是这样，记录缓存跟Memcached是一样的，还 不如用Memcached，更灵活。但接下来数据库内置记录级缓存的招数，基本上都是Memcached搞不定的。

　　2、如果仅仅如果更新命中了记录缓存中的记录，则只更新记录缓存，不更新底层的堆等存储。具体细化下来有UPDATE和DELETE两种，NTSE暂时只能搞定UPDATE；

　　3、 记录缓存里的东西，总是要有周期的持久化的，否则恢复时间不能保证。这个第叁招，就是持久化也就是把记录缓存中的脏记录dump出去的时候，不要去更新对 应的堆中的记录，否则短时间就会爆发大规模的随机读写，做法应该是像内存数据库那样，把脏记录用顺序写IO dump出来。NTSE就是这么做的，刷记录缓存脏记录时，我们先看看对应的页面在页面缓存中在不在，在，则更新堆，否则顺序dump到log中。

　　4、在更新时，可以只把UPDATE后的后像插入到记录缓存中，根本不去读塬来的记录，当然这个要看具体情况，如果后像是依赖于前像的那这招就不灵，但很多时候是可以用的，比如根据主键找到一条记录，不管3721把其中一些属性改掉。NTSE暂时还搞不定这招，有待改进。

　　记录缓存的这4招，消除数据库中记录操作带来的随机IO是很有效的。遗憾的是这不是必杀技，如果记录的访问确实的纯随机的就会失效，幸运的是这样的情况不常出现。

　　索 引的随机IO问题要更复杂一点。我们简单点，只说涉及到单个索引项的操作。传统的B+树，无论是搜索、插入还是删除（更新相当于插入+删除，就不额外讨论 了），理论上都是O（log（B）（N））次IO（其中B是页面包含的键值数，N是总键值数），但实际情况下可以假设非叶节点都在内存中，因此是1次 IO。磁盘一般只能有每秒几百次随机IO，因此对大的索引，每秒只能有几百次操作，这个性能真是低的可怜。B+树是70年代的老怪物，但直到今天，大多数 数据库里仍然用得是它，但实际上，有比传统B+树更能对付随机IO的东西。