谈数据库查询涉及的存储效率

(Owed by: 春夜喜雨 )

参考：

11月马上也进入尾声了；紧接着的12月，新年也就不远了…

今年对数据查询做了许多的分析、测试、修改、验证，慢慢进入了一个瓶颈期。或许是大的优化，好做的优化都已经实施了，下来都是比较难啃的硬骨头了。

下面就遇到的瓶颈点，与用过的或未曾用过的方式，大概记录记录。

注：想到什么写什么了，后面再慢慢修改补充。

查询优化与存储

对于数据查询来说，主要的瓶颈就在存储IO，磁盘IO的读写速度低于内存处理、CPU处理数个数量级。是查询效率优化的中心，优化也都于围绕着它展开。

下面图片来源于

减少不必要的IO

如何保留必要的磁盘IO，减少不必要的磁盘IO是一个比较关键的事情。

数据库中的元素通常按照block块存储，减少不必要block块或非目标块的读取就是一个比较重要的点。

例如设计比较好的索引归类方式，或过滤，也或其它方式，来减少无效的block读取，减少IO次数。

减少非连续IO

另外基于业务查询特点，查询之间可能存在天然的联系，例如查询账单，这一小时和下一小时的账单通常会被一起查询，那么如果他们在一个block中，或者相邻存储，则磁盘效率会比较高。

Cache的使用

一样的参考存储的效率差异，内存相对于磁盘，取数据要高很多。

从磁盘读取block块数据时，不要用完即扔，而是用完存储到内存Cache中，下次查询或许就用得到block中的其它数据，也或下次还会查该信息。

cache的使用，也用于减少了磁盘的IO次数，cache命中的次数越多，磁盘io的次数就相应的减少越多。

但cache也不能无限的增长，否则内存就不够用了，全cache到内存中，数据少还可以，如果上百GB以上的数据，无论如何不是很可行的。

如何优化Cache的淘汰方式，优化既要限定Cache大小，并要能够一定程度的保障Cache命中率又足够优秀，就是一个需要权衡的事情。典型的既要又要，常用的LRU算法算一种，像改进型的LRU（区分yong与old区域）也是都在争取既要又要。

的使用

的使用也勉强算一个点，写缓存的部分数据，是最近新写入的数据。

这部分数据，在某些业务中或许也是使用比较频繁的数据。

一方面解决写内存速度与写磁盘IO速度不一致的情况，另外足够大的写，也能为最新写入数据查询提供一定的便利，如果数据查到在写中，则也减少了向Cache或磁盘IO发起查询。

Cache的细分

再进一步，Cache细分：

有Block-Cache，有查询结果-Cache，有压缩Cache与非压缩Cache，有全局Cache与局部细分Cache。

不同的Cache种类，适用场景也不尽相同：

Block-Cache属于块Cache，不关心内容；-Cache是查询结果Cache，和用户查询动作相关；Block-Cache适用于预测，block内其它内容也可能被使用，也适用结果查了再查；-Cache适用于预测，查询会查了再查的情况；另外- cache单条查询结果通常比block要小很多。

有压缩的Cache与非压缩的Cache，两者差异是有无采用压缩，压缩的话可以在同样大小cache下增加存储的有效数据数量，相当于cpu时间换空间的效果，适用于希望限定cache大小规模缓存更多内容的情况。

全局Cache与局部Cache，就是分级Cache了，平衡业务特点，是把局部cache做大一些，还是全局cache做大一些。

局部性原理应用

我们知道局部性原理会提升cpu的处理效率，局部性原理好的程序代码，同样的任务执行时间更短，效率更高。对于计算密集型的如此，对于io密集型的更加显著。

局部性原理起作用应该就是各级cache换入换成造成的时间消耗差异。

对于io密集型程序，涉及的mem大小更大，也更频繁，对于局部性原理也就更加明显了。

程序优化时，适当的考虑局部性原理，会对查询效率带来帮助。

总而言之

总而言之，对于查询涉及的存储效率：

一方面减少磁盘IO的次数，一方面减少非连续IO的次数，对查询性能是很有帮助的，这块cache引入也是为此服务；另外考虑局部性原理，尽量操作相近的内存，也对查询有帮助。

(Owed by: 春夜喜雨 )