这两天在公司优化一个sql的时候碰到了一个诡异的事——一个表中的一个唯一性索引在更换了最左边的字段后,根据最左边字段为where后面的查询条件时,查看执行计划发现有些时候有用到索引,而有些时候则没有用到索引。
现象具体说明
出现问题的表结构以及其字符集如下:
alter table sodr_po_header add UNIQUE KEY sodr_po_header_u1(po_num, po_type_id, snapshot_flag,tenant_id);
show index from sodr_po_header;
explain select * from sodr_po_header where po_num = 'PO20190619000014';// 复合索引的最左字段
执行上面的sql语句后,有如下结果:
sodr_po_header表的索引为:
执行计划结果为:
显然此时是根据索引进行查找的。
然后更换复合索引字段顺序:
drop index sodr_po_header_u1 on sodr_po_header;
alter table sodr_po_header add UNIQUE KEY sodr_po_header_u1(po_type_id, po_num, snapshot_flag,tenant_id);
show index from sodr_po_header;
explain select * from sodr_po_header where po_type_id = 9; // 复合索引的最左字段
执行上面4条sql后,表的索引情况:
执行计划结果:
此时执行计划显示并未使用索引进行查找。
为什么会有上面这种现象
如上,为了找到会出现这种“bug”的原因,我额外建了一张表teacher用于测试,其表结构和字符集如下:
alter table teacher add UNIQUE KEY dept_uk_tt(tname, tid, gender);
show index from teacher;
explain select * from teacher where tname = 'tw'; // 复合索引最左字段
teacher表的索引情况:
执行计划结果:
此时是有用到索引的。
更换复合索引中字段的顺序:
drop index dept_uk_tt on teacher;
alter table teacher add UNIQUE KEY dept_uk_tt(tid, tname, gender);
show index from teacher;
explain select * from teacher where tid = 3; // 复合索引最左字段
teacher表的索引情况:
执行计划结果:
发现还是用到了索引进行查询操作,这个时候真的只能用上“震惊”二字了。
总结
目前我还是没有什么头绪,如果有大佬看到了这篇文章并且有解决方案或者任何提议,希望在评论里给我留言。当然,如果我找到了原因,同样会更新本文。