MySQL索引的尝试

关于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:联合索引的测试懒得贴了,有兴趣就自己试试呗。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容