MySQL联合查询、最左匹配、范围查询导致失效

服务器版本

客户端：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，发现联合索引是否失效与前面范围查询是什么字段无关，取决于后面的索引用了=还是!=符号，如果用了=则范围查询后面的索引也能使用，用!=则不行。而像>,<就铁铁的范围查询后面的列没有使用索引

• 我的实验

  • 使用的是Oracle之scott用户数据表emp，增加了三个sal=1500的用户
    在实验时测试了多组数据，得出来的结论都一样，这里只贴出1组数据供参考。
    所以最终我也不知道谁对谁错，等到我再牛逼一些，再把她搞清楚