「这是我参与2022首次更文挑战的第 1 天，活动详情查看：2022首次更文挑战」
在给前辈填坑的时候，发现某个操作耗时起步 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 中的大部分优化，都是尽可能的使用索引，避免全表检索？
原创文章，未经允许，禁止转载
create by：安逸的咸鱼
