教你怎么快速找到那些在mysql里跑得特别慢的sql语句，别再傻傻查不到重点了

最重要的一步是确保你的MySQL服务器已经开启了“慢查询日志”功能，这个功能就像是给数据库安装了一个监控摄像头，它会自动记录下所有执行时间超过你设定阈值的SQL语句，这是最直接、最全面的方法。（来源：MySQL官方文档关于慢查询日志的说明）

怎么开启呢？你需要找到MySQL的配置文件，通常是叫my.cnf或者my.ini，在这个文件里，找到并设置以下几个关键参数：

1. slow_query_log = 1：这个参数等于1就是开启慢查询日志，等于0就是关闭。
2. slow_query_log_file = /path/to/your/slow.log：这里要指定慢查询日志文件存放在服务器的哪个位置，记得确保MySQL进程有权限在这个位置写入文件。
3. long_query_time = 2：这是最关键的一个参数，单位是秒，它意思是，如果一条SQL语句的执行时间超过了2秒（你可以根据情况调整为1秒甚至0.5秒），就会被记录到慢查询日志里，对于网页应用来说，通常超过1秒的查询就已经算慢了。

修改完配置后,你需要重启MySQL服务，或者在不重启的情况下用SQL命令动态设置这些参数，让新设置生效。

一旦开启后,MySQL就会在指定的日志文件里记录下所有慢查询，你可以定期去查看这个日志文件，里面会详细记录每条慢SQL的执行时间、执行语句、以及当时的时间戳等信息，这是最基础也是最有效的一步。

光有日志还不够,因为日志文件可能会很大，手动查看效率很低，这时候就需要用到MySQL自带的一个神器工具，叫做mysqldumpslow。（来源：MySQL官方工具手册）这个工具可以帮你分析慢查询日志，它会将类似的SQL语句归类统计，告诉你哪些类型的SQL是“惯犯”，总共执行了多久，平均每次执行多长时间，你只需要在命令行里输入类似mysqldumpslow -s t -t 10 /path/to/slow.log这样的命令，它就会帮你列出平均耗时最长的前10条SQL语句，一目了然。

除了分析日志,在数据库正在运行的时候，我们也能实时抓取到那些当前正在执行的、性能有问题的SQL，这就需要用到MySQL的SHOW PROCESSLIST命令。（来源：MySQL SQL语句参考手册）你可以在MySQL的命令行客户端里直接输入这个命令，它会显示当前所有数据库连接正在干什么，你要重点关注的是“Time”这一列，它表示这个连接当前的操作已经执行了多长时间，如果看到某个SQL的Time值特别大，比如好几十秒甚至几分钟，那它很可能就是导致数据库变慢的元凶，你可以记下它的ID，如果需要，甚至可以用KILL命令终止这个查询，先恢复数据库的正常运行，然后再去仔细分析这条SQL的问题所在。

对于想要更深入、更实时分析的情况，尤其是在MySQL 5.7及以上版本，强烈推荐开启性能模式（Performance Schema）中的语句监控功能。（来源：MySQL Performance Schema官方文档）这个功能比慢查询日志更强大，它能记录所有SQL语句的执行情况（而不仅仅是慢查询），包括执行次数、锁等待时间、磁盘读写量等极其详细的数据，你可以在performance_schema数据库的events_statements_summary_by_digest这个表中进行查询，通过这个表，你可以轻松找到总耗时最长、或者平均耗时最差的SQL语句摘要，比如你可以用这样的SQL来查询：SELECT * FROM performance_schema.events_statements_summary_by_digest ORDER BY SUM_TIMER_WAIT DESC LIMIT 10;，这能帮你快速定位到消耗了整个数据库最多资源的那些SQL。

当你通过以上方法找到了这些“问题SQL”之后，接下来就是要对它们进行“解剖”了，最强大的解剖工具就是EXPLAIN命令。（来源：MySQL SQL语句参考手册）你只需要在任何一条SELECT语句前面加上EXPLAIN关键字再执行，MySQL就不会真正去查数据，而是会返回一个执行计划，这个执行计划就像SQL语句的“体检报告”，它会告诉你MySQL打算如何执行这条语句。

看执行计划的时候,要重点关注几个关键字段：

• type列：这代表了查询的类型，从好到坏大概是system > const > eq_ref > ref > range > index > ALL，如果你看到ALL，就意味着要全表扫描，这是最糟糕的情况，说明它可能没有用到索引，需要检查where条件里的字段是否建立了索引。
• key列：显示MySQL实际决定使用的索引，如果这一列是NULL，那基本可以断定是索引问题。
• rows列：MySQL预估为了找到所需的记录需要扫描多少行数据，这个数字当然是越小越好。

通过EXPLAIN分析，你就能知道SQL慢的具体原因：是没走索引？还是索引没被正确使用？或者是表连接（JOIN）的方式不好？找到了病根，才能对症下药，比如去优化SQL的写法，或者为相关字段创建合适的索引。

还有一些日常可以使用的技巧,很多图形化的数据库管理工具，比如MySQL Workbench、Navicat等，都内置了可视化的监控和诊断工具，它们本质上也是基于上面提到的那些命令和日志，但用图表展示出来会更直观，养成定期检查的习惯也很重要，可以每周或每月固定时间跑一遍上面的分析流程，防患于未然。

快速定位慢SQL的流程就是：先通过开启慢查询日志和利用工具进行宏观分析，找到目标SQL；然后利用SHOW PROCESSLIST或Performance Schema进行实时问题捕捉；最后用EXPLAIN命令对抓到的SQL进行微观分析，找出性能瓶颈并优化。 这套组合拳打下来，绝大多数慢SQL都无所遁形，排查慢SQL是一个需要耐心和细致的过程，但掌握了正确的方法，你就再也不会像无头苍蝇一样乱转了。