「这是我参与2022首次更文挑战的第16天，活动详情查看：2022首次更文挑战
怎么处理 MySQL 的慢查询这个问题，其实在工作场景里面用到的非常多。为什么？你知道你在工作中基本上做的都是一些 CRUD 的功能。如果你做这些功能的话，必然要跟你的数据库产生交互。这个时候根据你表的数据量，你表的规模都有可能会产生一些慢的 SQL 语句。当你遇到这些慢 SQL 语句的时候，我们应该怎么办？或者说我们应该通过哪些维度去考虑这些问题呢？
慢查询日志的开启
开启慢查询日志，准确定位到哪个 SQL 语句出了问题，这里的慢和快是没有一个正确的衡量值。所以你在进行统计的时候，可以开启一个参数。我就规定好，如果你当前查询超过了一秒钟，就认为是一个慢 SQL 语句，这个时候我可以把这些查询比较慢的 SQL 语句记录到日志中。我通过日志查询，能准确的定位到到底是哪一个 SQL 语句。然后针对不同的 SQL 语句进行优化就可以了。所以这是一个比较简单方式，叫慢查询日志。一般情况下我们都会进行开启的。
分析 SQL 语句
在 SQL 语句优化的时候，我们必须要看 SQL 语句，不看 SQL 语句是不知道如何优化的。分析 SQL 语句的时，看一下是否加载了一些额外的数据。我们在进行查询的时候，最好只加载我们需要的数据，任何不需要数据都不要加载。可能是查询了多余的行，并且抛弃掉了，也可能是加载了许多结果中并不需要列对要进行分析和重写。所以你要详细看一下你的搜狗语句有没有额外的行数据，有没有额外的列数据。
分析 SQL 执行计划
分析语句的执行计划，然后获取到其使用索引的情况，之后来修改或者修改索引，使 SQL 语句尽可能多的命中我们索引。索引是用来加快我们的数据访问，如果说你执行了一个 SQL 语句，它运行非常慢，你不看它的执行计划，你就直接想对它进行调优，这简直就是耍流氓。所以必须要先看执行计划，根据执行计划里面的显示信息再去进行优化调整。
数据表的扩展
如果对于优化已经无法进行了，可以考虑表中的数据量数太大了。这个时候我们可以把我们当前的表进行横向或者纵向的一个切分，比如我尽可能小的去查询我们的数据，而不是说把所有的数据范围我都查询一下。比如一个表有一千万数据，我每次要都查1千万，太慢了，我能够把它分成0到2百万。这样以此类推，相当于我限定好了每一个小的数据范围，只需要从某一个小范围里面检测数据就可以了。我检索2百万数据和检1千万数据效率肯定是不同的。所以把这些就要考虑的维度，都要考虑进去。
