MySQL 索引使用笔记

leokim / / MYSQL

用voucher表来做单表测试

  1. 创建voucher_id为主键

  2. 创建voucher_idx(voucher_id, prefix, voucher_no)

    image.png

当我查主键的时候毫无疑问 肯定是走主键索引的

image.png

当我只查找主键字段的时候 Extra显示“Using index”不回表直接使用到覆盖索引

image.png

可以看到 当查询条件里有主键的时候 查询会直接用主键查询 可能是因为主键是唯一索引 直接就定位到是最简方法

image.png

下面不用主键来做条件， 直接用voucher_idx里的字段来查找

可以看到type变成了ref 不再是有主键时的const

ref：是一种索引访问（有时也叫索引查找），它返回所有匹配某个单个值的行。然而，它可能会找到多个符合条件的行，因此它是查找和扫描的混合体…

可以看到找到了45310条记录，测试的voucher总数是319814  45310/319814≈0.15 不到30%所以还是能使用索引的

image.png

但是这就不对了 prefix是‘A10’的占了76% 还是能用到索引 是不是说明“一个值超过30%就无法使用索引”的描述？ 可能是新版功能加强了吧

image.png

这个确实能证实，不是从索引左侧的列搜索用不到索引，这条语句扫描了319814行

image.png

下面这个语句 其实说明了不按索引顺序 也是能用到索引的 应该是索引优化器把where里的索引列又排了下

image.png

查了一下优化器执行的代码 好像也没有对索引重排 看来还是service层做了优化让我们能使用到索引？

image.png

我又创建了一个索引voucher_idx2,我以为搜索条件是voucher_no, prefix和 prefix,voucher_no的时候会不一样，结果都用到了voucher_idx2

image.png

image.png

image.png

这可以说明当查询条件和搜索条件都在索引内时，不按索引顺序也是能用到索引的，但是扫描了全表

image.png

image.png

但是查询列或者搜索列里有不在索引列里的列的时候 是会扫描全表的

image.png

image.png

那我把所有列都拿进来 是不是都能用到索引？？ 

image.png 

可以看到，其实是走了索引，但是也是扫了全表，效率应该相当差， 需要用数据量很大的库来试一下，如果不按索引顺序来跑的效率

image.png