面试官：如何分析SQL执行效率

快速学会分析SQL执行效率(上)

勤学如春起之苗，不见其增，日有所长。 ——陶潜

本篇一起讨论一下SQL优化，而SQL优化前提要能定位到慢SQL并对其进行分析，因此会跟大家分析如何定位慢查询和如何SQL执行效率。

在我们工作可能遇到某个新功能在测试时需要很久才返回结果，这时就应该分析是不是慢查询导致的。如果确实有慢查询，又应该怎么去分析SQl执行效率呢？本篇就来学习怎么慢查询和怎么去分析SQl执行效率。

1、定位慢SQL

在我们实际工作中，碰到某个功能或者某个接口需要很久才能返回结果，我们就应该去确定是不是慢查询导致的。定位慢SQL有如下两种解决方案：

• 查看慢查询日志确定已执行完的慢查询

• show processlist 查看正在执行的慢查询

1.1 通过慢查询日志

慢查询：是指在数据库中执行的查询操作所花费的时间超过了预期的阈值，通常是由于查询涉及大量数据、索引未正确使用或者数据库性能不佳等原因导致的。

如果需要定位到慢查询，一般方法是通过慢查询日志来查询的，MySQL的慢查询日志用来记录在MySQL中响应时间超过参数 long_quey_time(默认10秒)设置的值并且扫描记录数不小于 min_examined_row_limit(默认0)的语句，能够帮我们找到执行完的慢查询，方便我们对这些 SQL 进行优化。

知识扩展：

默认情况下，慢查询日志中不会查询管理语句，可通过设置 log_slow_admin_statements = on 让管理语句中的慢查询也记录到慢查询日志中

默认情况下，也不会记录查询时间不超过 long_query_time,但是不使用索引的语句，可通过配置log_queries_not_using_indexes = on 让不使用索引的SQL都被记录到慢查询日志中(即使查询时间没超过long_query_time配置的值)

如果需要使用慢查询日志，一般分为四部，开去慢查询日志、设置慢查询阈值、确定慢查询日志路径，慢查询日志的文件名。

首先开启慢查询日志，由参数 slow_query_log决定是否开启，在MySQL命令行输入下面命令：

mysql> set global slow_query_log = on;  //开启  

默认环境下，慢查询是关闭的。

设置慢查询时间阈值：

mysql> set global long_query_time = 1  //单位:秒

MySQL中long_query_time的值如何确定呢？

线上业务一般建议把 long_query_time 设置为 1 秒，如果某个业务的 MySQL 要求比较高的 QPS(每分钟执行查询次数)，可设置慢查询为 0.1 秒。发现慢查询及时优化或者提醒开发改写。

一般测试环境建议 long_query_time 设置的阀值比生产环境的小，比如生产环境是 1 秒，则测试环境建议配置成 0.5 秒。便于在测试环境及时发现一些效率低的 SQL。

甚至某些重要业务测试环境 long_query_time 可以设置为 0，以便记录所有语句。并留意慢查询日志的输出， 上线前的功能测试完成后，分析慢查询日志每类语句的输出，重点关注 Rows_examined（语句执行期间从存储引擎读取的行数），提前优化。

确定慢查询日志路径

慢查询日志的路径默认是MySQL的数据目录