- 如果查询条件是
where A=a1 or B=b1，数据库不会使用这个索引
for a in A {
if a == a1 {
as = append(as, a)
}
}
for b in B {
if b == b1 {
bs = append(bs, b)
}
}
// as 和 bs 的并集就是你要的结果
- 如果查询条件是
WHERE A=a1 AND B > b1 AND C = c1，查询只会使用索引的A和B两列
for a in A {
if a == a1 {
for b in B {
if b > b1 {
// C 是无序的，所以用不了。你可以从前面的表格里面看出来
// 比如说 b > 23 之后，对应的 C 是乱序的
// 这就是你要的结果，去磁盘里面读取
}
}
}
}
- 如果查询条件是
WHERE A !=a1，那么这个查询也不会使用索引。
判断会不会使用索引，需要按照组成索引的列的顺序，从左往右：AND 用 OR 不用，正用反不用，范围则中断。这里只是联合索引的规则，有一些意外的情况也不符合这个口诀描述的规律，比如M=1 OR N=2，如果单列M上有一个索引，单列N上也有一个索引，可能也会使用M/N上的两个索引。可以看EXPLAIN命令的输出。
索引的代价
索引是一个以空间换时间的设计思想，会消耗很多的系统资源，比如：
- 额外的磁盘空间：索引需要存储在磁盘里
- 额外的内存空间：运行的时候，索引会被加载到内存里
- 额外的计算：在增删改数据的时候，数据库还需要同步维护索引
常见面试问题
索引和索引优化，强调一般情况下，忽略数据库有别的索引、或者查询条件过滤效果不好导致数据库不使用索引的情况。
- 性能优化 -> 索引优化
- 是否了解B树、B+树
- 聚簇索引、覆盖索引
- 数据一定会索引吗
使用索引的性能一定好吗？综合考虑索引本身的开销以及数据库不用索引的情况
基本介绍索引的思路是按照B+树、索引分类和最左分配原则来介绍。
数据结构方面，MySQL里的索引主要是B+树，它的查询性能更好，适合范围查询，也适合放在内存里。
MySQL的索引可以从不同的角度进行分类，比如根据叶子节点是否包含数据分为聚簇索引和非聚簇索引、包含某个查询的全部列的覆盖索引等。
数据库使用索引时遵循最左匹配原则，但是数据库最终会不会使用索引，跟查询/数据量有关。
- 为什么MySQL使用B+树，而没有使用B树/二叉树/红黑树/跳表？
一个数据结构是否适合数据库索引，取决于数据结构的增删改查性能，而且还要去范围查询友好，减少内存消耗和磁盘IO次数。
- 与B+树相比，B树的数据存储在全部节点里，而且叶子节点没有用链表进行连接，对范围查询不友好。非叶子节点里存储了数据，导致内存里难以放下全部非叶子节点，意味着查询非叶子节点的时候就需要磁盘IO。
- 与B+树相比，平衡二叉树、红黑树在同等数据量下，高度更高，磁盘IO次数更多，性能更差。而且它们会频繁执行再平衡过程，来保证树形结构平衡。
- 与B+树相比，跳表在极端情况下会退化为链表，平衡性差。而且跳表的查询时间无法预估，需要更多的内存。
为什么数据库不使用索引
比如前面的索引
<A,B,C>里，假设A的所有值都是正数，使用查询条件where A > -1的时候，数据库会觉得还不如全表扫描，所以实际并不会用索引。一般来说，数据库可能不使用索引的原因有以下几种：
- 使用了
!=,LIKE之类的查询 - 字段区分度不大，比如
A列只有0,1两个值 - 使用特殊表达式，比如数学运算和函数调用
- 数据量太小，或是觉得全表扫描更快的时候
上述的原因只是可能的情况，
LIKE查询的时候，如果只是Like ab%这种前缀查询，可能也会使用索引。还有一些SQL提示，比如FORCE INDEX（强迫使用索引）、USE INDEX（使用索引）或者 IGNORE INDEX（忽略索引），关键是取决于数据库。
还有一种说法是，含有NULL的列上的索引会失效。不过这个说法并不准确，实际上MySQL还是会尽可能的使用索引。
- 使用了
索引和NULL值
不同的数据库可能会有差异。
MySQL本身会尽可能的使用索引，即使索引的某个列有零值，而且
IS NULL和IS NOT NULL都可以使用索引。而且MySQL的唯一索引里允许多行的值都是NULL。但是不管从什么角度，使用NULL都是比较差的写法
其他思考
有没有遇到过索引设计不合理引发的线上事故？如何定位问题+解决的？
有没有因为NULL遇到过问题？
