记录一次实际过程中的 MySql 数据库 SQL 优化

前言

之前开发项目的过程当中数据库存储的数据量都不是很大，在表的设计当中就只有一个主键索引。很少接触到数据库的索引，SQL 优化这些东西。公司目前的项目数据达到了百万级别了，让我优化一下慢 SQL，之前是懂一些 SQL 优化和索引相关的理论知识，没有实际操作过，特此记录优化的过程和思路，事实证明，理论和实操还是有不少区别的。

理论知识

• SQL 的优化大部分都是和索引相关，所以对索引的相关知识一定要有很深的理解。网上关于索引的文章很多，这里推荐一篇比较好的文章：MySQL 性能优化之索引优化
• SQL 的优化也有对本身 SQL 代码的优化。比如 not in 和 exists 这种。详见： sql 优化的几种方法
• EXPLAIN 语句的运用和了解：MySQL Explain 详解
• 运行 SQL，总得有一个执行的顺序吧？SQL 语句执行顺序

实际过程

理论是基础，在实际的过程当中需要灵活的运用。特此记录自己在进行优化时的一些操作和心得。

1. 查看执行语句选择的索引，一次查询只会选择一个索引，是 mysql 自动进行的选择。 但是 mysql 并不会总是选择我们希望的索引。所以要结合索引的相关知识让 mysql 选择到我们希望的索引。
2. 在 1 的基础上，需要注意，当我们新建一条索引之后，可能会导致之前某些 SQL 在索引的选择上发生变化。
3. 结合业务场景进行 SQL 方面的优化，当需要连表进行 count 操作的时候，如果两张表的数据都很大的话，可以先考虑 group by 在用 sum 统计！等等之类的操作（需要查看大量理论相关的知识）
4. 索引不是越多越好，合理的索引会加快查询效率，不合理的索引也可能会加快效率，但是会提高维护成本！
5. 光有索引也不行，还得结合 SQL 进行优化，思考为什么慢，慢的原因可以避免么？慢的 sql 可以变换么？。
6. 考虑 SQL 当中的某个操作是否可以避免，或者替换，比如：存在联合唯一索引：dept_id 和 user_id，那么当 dept_id 为查询条件的时候，对 user_id 的去重操作就可以取消掉。
7. 如果 SQL 上优化不了，那就从业务上优化。
8. 最后一定要有耐心，优化的过程是很枯燥的！！！！！

注意点

• 保证测试环境和正式环境的数据，SQL，机器配置一致。
• 有时可能是正式环境进行了限流操作，结果本地跑的飞起，正式卡的飞起。