MySQL索引优化--对前缀索引使用like模糊匹配时的实际索引选择
由于我在最近的项目中对mysql的某张表的某个varchar列加上前缀索引后，这张表主键为id，其他列没加索引，在查询语句中即使where子句里只有course_num like "4%"这个条件，SELECT * FROM test WHERE course_num LIKE "4%"，通过使用explain发现还是会走all类型进行全表查询。随后，我发现用绝大多数的博文中的数据进行复盘测试时，得到的结果和他们的对不上，在翻阅MySQL的查询优化器相关知识时，绝大多数博文中写的形如"4%"这种百分号在后面的一定会走range类型用前缀索引进行查询，这不是绝对正确的，在一些情况下不会走前缀索引查询，可能这些博文默认读者已经知晓了查询优化器的某些前置知识。然而实际上需要结合查询优化器基于成本计算去选择是否使用索引。这里就不再赘述索引选择性。好了，废话不多说，看下面的测试用例的演示。
首先建立数据表和前缀索引（在本例中由于varchar列长度太短所以对整列建立前缀索引），其中本例用到的前缀索引为index_uname。
CREATE TABLE test(
id INT NOT NULL AUTO_INCREMENT,
major_abbr VARCHAR(5) NOT NULL,
course_num VARCHAR(5) NOT NULL,
PRIMARY KEY(id),
KEY index_course_num(course_num)
)ENGINE=INNODB DEFAULT CHARSET=utf8mb4;
然后插入10条数据：
INSERT INTO test VALUES (NULL,"CS","2000"),(NULL,"CS","2100"),
(NULL,"CS","3000"),(NULL,"CS","3100"),(NULL,"CS","3500"),(NULL,"CS","3600"),
(NULL,"CS","4000"),(NULL,"CS","4100"),(NULL,"CS","4200"),(NULL,"CS","4500");
先获取全部数据：
select * from test;
id major_abbr course_num
1 CS 2000
2 CS 2100
3 CS 3000
4 CS 3100
5 CS 3500
6 CS 3600
7 CS 4000
8 CS 4100
9 CS 4200
10 CS 4500
查询test表中course_num列前缀为4的所有行。
-
计算返回的行数占表的总行数的比例：
SELECT (SELECT COUNT(*) FROM test WHERE course_num LIKE "4%")/COUNT(*) AS proportion FROM test;proportion 0.4000再用explain分析：
EXPLAIN SELECT * FROM test WHERE course_num LIKE "4%";id select_type table type possible_keys key key_len ref rows Extra 1 SIMPLE test ALL index_course_num \N \N \N 10 Using where看见ALL，发现走的全表查询，此时的返回行数占总行数的40%。
-
修改test表的最后一行的course_num列为'3500'：
UPDATE test SET course_num='3500' WHERE id=10;
这时再获取test表全部数据看一下：
先获取全部数据：
select * from test;id major_abbr course_num 1 CS 2000 2 CS 2100 3 CS 3000 4 CS 3100 5 CS 3500 6 CS 3600 7 CS 4000 8 CS 4100 9 CS 4200 10 CS 3500计算返回的行数占表的总行数的比例：
SELECT (SELECT COUNT(*) FROM test WHERE course_num LIKE "4%")/COUNT(*) AS proportion FROM test;proportion 0.3000再用explain分析：
EXPLAIN SELECT * FROM test WHERE course_num LIKE "4%";id select_type table type possible_keys key key_len ref rows Extra 1 SIMPLE test range index_course_num index_course_num 22 \N 3 Using index condition看见range，发现走的index_course_num索引查询，此时的返回行数占总行数的30%。
对于like后跟形如"4%"百分号放在尾部的查询条件的结论：这种百分号放在尾部的查询条件在实际执行中不一定会去使用前缀索引，因为在mysql查询优化器中基于成本计算是否使用索引的代价有这样一种方式--我们在用前缀索引也就是辅助索引进行模糊匹配时是有序的，辅助索引也是用b+tree存放的，在该b+tree的叶子节点存放的对应的主键值一般情况下不是有序的，这样可以认为取的每一行记录都需要读取磁盘一次（表的数据在磁盘中划分为块的形式，在内存中划分为页的形式），记test表在磁盘上所占的块数为\(B\)，执行上述查询语句返回的行数为\(T\)，当T足够大的时候也就是大致的\(T>B\)，这时候走全表查询会比走辅助索引到主索引查询更优。当然，如果\(T\)足够小的时候，走索引查询更优。这个\(T\)和\(B\)的关系通常用放回的行数占总行数的比例去衡量，目前来说没有一个固定的临界值，一般的经验值为30%，所以这就是为什么在上述第一种情况下会走全表查询，而在上述第二种情况下会走前缀索引查询。在实际情况中是否使用索引还要根据这个比例（COUNT(*)等等除外），当然MySQL查询优化器最终选择的索引实际上也不一定是最优的，由此其他文章中写的形如百分号放后面的like匹配一定会使用前缀索引是不够robust。这样的话我们在分析sql语句的效率时，可以加上FORCE INDEX (index_name)强制使用index_name索引，配合explain去分析查询返回的行数占总行数的比例，这种也可以用于找到合适的前缀长度。
如果觉得我解释的某些地方有歧义的，欢迎指出。
