顺序IO、随机IO与索引

     上面提到 "索引建的不好的一般的结果是没有走索引也就是索引没起效这种结果就是扫全表，但是有些时候你可能会发现走了某些索引的查询可能会比扫全表更慢"。why？这就需要分析顺序IO与随机IO的区别了。顺序IO指的磁盘沿着扇区一直扫，比如磁盘的读取速度是40M/S,一条记录的大小是400Byte。那读取一条记录的时间是0.01ms。而一次随机IO理想的估算是大概是10ms左右，分析如下所示。

      比如从一个10W条记录里面读取2000条记录如果是扫全表那花的时间是

      10ms + 100000 * 0.01ms ~= 1s

       如果是随机I/O：

       2000 * 10ms = 20s;

       所以如果你的建的索引并没有把随机I/O变成顺序I/O那就可能会出现上面的这种情况了。不过有时候也不必要太担心，因为db都有一个叫优化器的东西，优化器往往能够分析出这种成本，帮你选择一种合理的执行方式。       

      索引是唯一提升查询速度的因素吗？

       这个当然不是了。在《系统性能优化二三事》中我们提到缓存是一种性能优化的方式~。其实这在db查询也是一样的道理，比如mysql服务器会预加载索引和表行数据进到缓存里面，如果缓存已经有了需要的数据，那就不需要读一次磁盘，而我们的磁盘也有一层缓存，如果磁盘缓存里面有需要的数据，也不需要进行一次物理文件的读取。所以缓存的设置也是很重要的。

      索引的误区和注意的地方。

      1、索引的层级不要超过5层。这条是常见的索引规范，其实这条的规范是有一定的适用范围的，并不是绝对的适用。因为提出这条规范的时候当时的计算机的内存还是非常的小，内存能放的东西非常的有限。如果索引的层级太多，那内存就可能放不下索引，这样读索引就要读一次磁盘，这性能就很差。但现在的计算机内存的容量比当时已经增大了成千上百倍，即使时是超过5层的索引也是可以放到内存里面。索引的层数越多，那过滤的效果就越好，实际读取的表数据就越好。

    2、单表的索引数不要超过六个。这个其实也是有适用范围的。提出这个规范的原因一方面是上面提到内存问题，另一个是表频繁更新问题，因为如果更新表的索引列索引也是更新的，索引的更新最终也会写回到磁盘。这就会增加磁盘的负载，影响整个数据库的性能。但如果这个表是不怎么更新的呢，更新频率很低或者不存在瞬间密集的更新，其实建立超过六个的索引也是可以的。

     其实索引还有很多东西可以讲，不过要讲清楚的话恐怕还要个十篇八篇才行。。。现在就暂说到这~。后面有时间再陆续分享。    

     阅读容易，码字不易。如果你喜欢我的文章或者觉得有所收获就请你点下关注或者推荐吧。这样作者才更加有写下去的动力~。