关于MySQL索引的命中问题，做了一点测试。
首先，关于索引无法命中的问题，查了不少资料，大概是这么说的：
- 在使用LIKE关键字进行查询的查询
如果匹配字符串的第一个字符为“%”，索引不起作用。只有“%”不在第一个位置，索引才会生效。
- 使用OR关键字的查询
查询语句的查询条件中只有OR关键字，且OR前后的两个条件中的列都是索引时，索引才会生效，否则，索引不生效。
- 使用联合索引的查询
只有查询条件中使用了这些字段中第一个字段时，索引才会生效。
我写了两百来万数据，测试了一下。
首先是LIKE查询，id是主键，t_password建了索引，
- 当前面没有"%"，rows是1325119条（password_school是我建的t_password和t_school的联合索引，后面会用到）；
EXPLAIN
执行时间
- 前面有"%"时,rows是2690239，可是看到此时possible_keys是null,看起来确实是全表扫描了，但是key是有值的（password是我建的t_password的索引名字）；
EXPLAIN
执行时间
可以看出，执行时间慢了不少。
那么假设是没有索引的字段呢？
EXPLAIN
执行时间
可以看到，执行时间比有索引的的模糊搜索慢了很多。
既然前面加"%"无法命中索引，为什么执行速度却还是比没有索引的字段快这么多呢？
- 从EXPLAIN里面可以看到，当前面不加"%"，rows是1325119；而前面加了"%"时，rows是2690239，也就是表的总行数，没有索引的字段pic_url也是2690239，但是这两者速度差了好几倍。
我的想法：LIKE查询有索引的字段，关键字前面没有"%"时，是可以准确命中索引，直接查符合条件的行；而关键字前面有"%"时，无法命中索引，但是执行时也是全索引搜索，而不是全表搜索，执行速度比不加索引还是快了很多的。
关于联合索引其实也是一样的，如果只给出了第一个条件，是能准确命中索引的；而如果没有给出第一个条件，只给出第二个，无法准确命中索引，但是也是全索引扫描，速度其实也比较快（当然不如准确命中索引，数据量越大就越明显），图就不上了，有兴趣的可以自己试一试。
我的结论：广为流传的几个索引失效的问题，其实并不是索引失效，只是索引不能准确命中，速度会相对慢一点，但也远快于没有索引的字段。
刚了解索引的时候就在想，MySQL怎么这么笨呢，动不动就不能命中索引。其实并没有那么笨。
ps：联合索引的测试懒得贴了，有兴趣就自己试试呗。
网友评论