0

如题, 我一直以为 select * from 表 where 索引列=xx and 非索引列=yy 一定会走索引列的索引.
但是今天发现, 并不是这样.
经测试(MySQL 5.6.16):

  1. 当联合条件能够匹配到记录时, 索引.
  2. 当联合条件不能匹配到记录时, 不走索引.

按照我的预期, mysql优化器用索引列扫描, 没有找到, 直接返回不就得了, 不用再管后面的非索引列了.
但是, 按照上面的测试来看, 很有可能是, 先走索引列, 发现没有对应的记录, 然后全表扫描了下.

另外, 即使使用了force index (索引列的索引)依旧是上面的情形.

示例:

id是索引列, content_type是非索引列.

联合条件匹配无记录时

clipboard.png

联合条件无匹配记录时

clipboard.png

测试表的结构

clipboard.png

开启prifiling后

执行SQL:
select sql_no_cache * from 表 force index(primary) where id=5 and content_type='电话'; (联合条件匹配不到记录的场景)

查看profile信息:
clipboard.png

Nisus 92
2018-12-07 提问

查看全部 2 个回答

1

已采纳

你这个例子怎么看出没用索引呢?你的id和content_type列都属于主键索引的索引内容,也就是说,你的查询是在一个const table里面进行,所以查不到数据会显示Impossible WHERE noticed after reading const tables。其他情况一般是显示using where的。
这里的Impossible WHERE是告诉你,在主键索引里,没找到你想要的行,主键也是索引呢,别歧视他,老铁。
另外,你要做实验,应该用非主键索引来弄。

你可能感兴趣的

推广链接