服务器版本
客户端:navicat premium16.0.11
联合索引
假设有如下表
- 联合索引就是同时把多列设成索引,如(empno,ename)
- 在查询的时候就会先按照empno进行查询,再按照ename进行查询
- 其中empno是全局有序,ename是局部有序。什么意思呢?
- B+树在构建的时候,由于联合索引遵循最左匹配原则,所以,按照从左往右的优先级进行选择,那么当遇到empno相同的时候,就会按照ename进行匹配。
- 在这个过程中,ename只有在empno相同的时候才会进行匹配,那么他在之前就没有必要排序,在empno相同的时候有序即可。
最左匹配原则
- 如果SQL 语句中用到了联合索引中的最左边的索引,那么这条 SQL 语句就可以利用这个联合索引去进行匹配,用上例(empno,ename)举例,只有当查询中where 后面出现empno,即联合索引中最左边的列,才会使用联合查询,单单使用
where ename=×××
是不会用到联合索引的 - 注意! 当遇到部分范围查询符号,后面的列可能不会走索引。(这一点有些难搞,其中对于各种范围查询导致索引失效的问题说法有多种)
与网络其他说法&小林coding中的实验结论不一致
- 注意!在小林coding中说到[原文],关于范围查询对联合索引的影响对于 >=、<=、BETWEEN、like 前缀匹配的范围查询,并不会停止匹配。并且给出了他的实验结果。而全网其他说法是所有范围查询都会导致联合索引右边的索引失效。
- 但是我的实验结果显示:
- 关于小林coding提到的几个例外,我试验了
>=,<=以及BETWEEN AND
,发现联合索引是否失效与前面范围查询是什么字段无关,取决于后面的索引用了=还是!=符号,如果用了=则范围查询后面的索引也能使用,用!=则不行。而像>,<
就铁铁的范围查询后面的列没有使用索引
- 关于小林coding提到的几个例外,我试验了
-
我的实验
- 使用的是Oracle之scott用户数据表emp,增加了三个sal=1500的用户
在实验时测试了多组数据,得出来的结论都一样,这里只贴出1组数据供参考。
所以最终我也不知道谁对谁错,等到我再牛逼一些,再把她搞清楚
- 使用的是Oracle之scott用户数据表emp,增加了三个sal=1500的用户