索引总结

这是数据库索引相关内容的最后一篇
复制代码

对于单表，咱们知道了如何设计《最佳索引》;

可是现实中，每每比较复杂，有联合查询、嵌套查询、子查询等等；咱们从如下几方面展开

1. 对优化器来讲难的谓词
2. 跨表查询
3. 设计出色索引的步骤

1. 对优化器来讲难的谓词

咱们来猜一猜，优化器比较难处理的谓词可能有哪些？

确定要排除AND，这足够简单；大于/小于呢，单纯来看也还行；between and呢；有范围，应该能接受，那还有什么？
好比Or,这明显对优化器有点难了，为何，由于它是不知足A，还得看B，等根据查询结果来进行判断需不须要看B；
还有LIKE, 若是LIKE以%开头，那么无疑给查询带来了难度；
复制代码

因此呢，难的谓词有什么？

对，就是or、like、in这些，没有办法经过简单的扫描得出结论的，不建议在这些列创建索引。
复制代码

这些谓词，咱们有个统一的称呼，称呼他们为非布尔谓词。那么相反，
简单直接的谓词就是布尔谓词，就是好的谓词，能够创建索引

2. 跨表查询

跨表查询总结起来就是自个表的部分，以及链接处.

1.链接处是否在索引中很重要
2.就算每一个单表都是最佳索引，可是若是有大量随机IO，仍然会致使查询慢

select CNO, CNAME FROM TABLE1 WHERE CTYPE = 1;
select DNAME FROM TABLE2 WHERE DNO = CNO AND DCOM = 2;

对于TABLE1,最佳索引为（CTYPE, CNO, CNAME）；
对于TABLE2,最佳索引为（DNO, DCOM, DNAME）;

乍一看，若是这两表联合查询，应该没啥问题，经过CNO连接，CNO也在索引中；

实际呢，在TABLE1中，CTYPE=1查出来的CNO，可能不止1个，假设1w个；那么对于没个CNO，都会触发TABLE2进行随机访问
咱们能够粗略大概计算一下LRT

LRT = 10ms + 1w*0.01ms + 1w * 10ms

对于TABLE1,数据所有在索引中，访问第一条索引起生了一次随机访问，剩余索引为顺序访问，因此是10ms + 1w*0.01ms
对于TABLE2,其访问顺序取决于TABLE1获得的CNO，CTYPE=1的状况下,CNO顺序存储的几率不大，咱们假设他们是分散存储的，那么每次FETCH CNO，就会致使一次随机访问索引，大概有1W*10ms的时长

最终，查询速度并不理想，虽然每一个表都是最佳索引，问题在哪？在于跨表查询致使的随机访问；
复制代码

在上述状况下，如何快速提高速度，若是在设计阶段，不妨考虑将两表合并，或者将CTYPE,也放入到TABLE2中；

每每你们特别排斥冗余数据，可是从效率的角度出发，冗余数据真的很差吗，它的维护成本和效率成本有没有好比如较一下呢？

固然若是实际运行中数据查询并不慢，并不须要纠结这些；若是可以经过宽索引或者半宽索引解决，就最好不要推翻或追加。

3. 设计出色索引的步骤

1.当表结构设计出来时，就该开始索引的设计
2.用BQ或者QUBE进行索引设计检查，若是仍是没办法知足需求，就要考虑合并表，减小跨表
3.根据应用须要尝试继续添加必要的索引
4.若是表增删改的频率很高（50次/秒），那须要用QUBE评估下最多允许添加多少索引
5.根据具体的数据库调整策略
6.SQL编写之后，继续使用BQ、QUBE、BJQ等方式进行检查
7.发布后，使用EXPLAIN进行检查
8.跟踪报告
复制代码

其余相关章节
复制代码

数据库索引相关文章之一：《B树，一点都不神秘》
数据库索引相关文章之二：《B树很简单,插入so easy》
数据库索引相关文章之三：《索引》
数据库索引相关文章之四：《什么索引算是好的索引》
数据库索引相关文章之五：《如何发现及替换不合适的索引》
数据库索引相关文章之六：《索引总结》