【MySql 项目实战优化】通过执行计划分析追加索引

在给前辈填坑的时候，发现某个操作耗时起步 5s 以上，把所有的 sql 都巴拉出来，发现在不修改业务逻辑的情况下可以解决的也就这一个，虽然优化 0.5s -> 0.1s 效果不是太明显，但起码我会一点点优化操作了🐶

先看原始的 sql 语句，t 表左连接 t1 表进行查询：

本次的耗时约为 0.5s，但查询后的结果有 2170 条记录，即 t 表中预计仅仅 2000+ 数据，这个执行的速度有点不对劲

使用 explan 来分析这一条 sql 的执行

发现都走起了全表索引。那么，一个最大的可能就是，t 表查询的时候，链接 t1 表获取额外的数据时，t1 表每次匹配的时候都走了一次全表检索

由于不是太理解执行计划中的 type=all 表达的含义，当时也不是太能区分出各个连接查询的差异，那就决定看看右连接和内连接的查询速度和执行分析：

右连接

相当于是以 t1 表主表，连接匹配 t 表中的数据，从执行计划中可以看出，t1 走的全表扫描，但是，t 表在匹配的时候，实际使用了主键优化匹配效率。

内连接

右连接和内连接的执行计划都是一样的，除了查询返回的结果有所差异

对比发现的右连接和内连接的查询效率是最高的，因为关联的表走的索引查询；而左连接查询，两个表都是走的全表查询

从 sql 上分析，t 表使用的是 id 字段，这个通常都是主键，t1 表使用了 xx_id 字段，每次都去走的全表索引，大概率是没有为其创建索引

打开 attribute_1 这个表的设计，发现没有定义任何索引（除主键）。

现在，为 xx_id 追加常规索引

测试验证追加索引后原始 sql 的性能

可以看到，查询的性能有了很大的进步 0.5s -> 0.09s

检查执行计划：

左表继续全表查询，但右表确确实实走了索引，这就是性能提升的原因，也验证了我之前提出的猜测

或许，mysql 中的大部分优化，都是尽可能的使用索引，避免全表检索？