MySQL 优化实战之关注组合索引的key_len

慢SQL

今天收到开发人员反馈，一个SQL输出结果只有79行，没有任何聚合函数。 但有6个表的join 速度很慢需要11S

只为了说明问题与脱敏，原语句有改动。

SELECT *
FROM T1 a
JOIN T2 p ON a.ID1 = p.ID1 AND a.ID3 = p.ID3 
WHERE a.XXX1 = 1
	AND a.XX2 = 2
	AND a.XX3 = 3
复制

T1表数据有300W ,T2表有400W

但T1符合条件的最后只有79行

查看执行计划

通过执行计划可以看到 T2表扫描行数达到了 138W ,明明是3键的组合索引 只用到了第一个键

组合索引是（id1,id2,id3） 看上面关联 on a.id1 = p.id1 and a.id3 = p.id3 开发没有写第二个键id2的关联条件。根据最左原则。id3是不能走上索引的。 通过Key_len=4 也可以确认，只用到了p.id1这个字段

我以为是业务需要。不能写a.id2=p.id2 准备新建一个索引。跑去咨询开发， 开发回复此语句关联写成 on a.id1=p.id1 and a.id2=p.id2 and a.id3=p.id3 语义是不变的

改写SQL 再看执行计划

SELECT *
FROM T1 a
JOIN T2 p ON a.ID1 = p.ID1 AND a.ID2 = p.ID2  AND a.ID3 = p.ID3 
WHERE a.XXX1 = 1
	AND a.XX2 = 2
	AND a.XX3 = 3
复制

T2表扫描行数变成了1行。 key_len 变成了20

执行时间从11s变成了0.047S 性能提升了234倍

总结

当我们使用组合索引时，不管是在join处，还是在where处 都需要关注key_len 是不是整个组合索引都使用上了。还是只使用了前几个Key.