MySQL慢查询日志用于捕获执行超阈值的SQL，需手动启用：临时开启用SET GLOBAL slow_query_log='ON'，永久配置需修改my.cnf并重启；分析用mysqldumpslow或pt-query-digest；优化前须EXPLAIN看执行计划，关注type、key、rows和Extra字段。
MySQL慢查询日志是数据库内置的性能诊断工具，专门用于捕获执行时间超过指定阈值（如1秒、2秒）的SQL语句。它不记录快查询，只聚焦“拖后腿”的语句，是定位性能瓶颈最直接、最常用的起点。
怎么开启和配置慢查询日志
默认关闭，需手动启用：
- 临时开启：执行 SET GLOBAL slow_query_log = 'ON';，立即生效但重启后失效
- 查看当前状态：运行 SHOW VARIABLES LIKE 'slow_query_log%';，确认是否开启及日志路径
- 设置阈值：用 SET GLOBAL long_query_time = 1; 将慢标准设为1秒（注意：该命令在新连接中才生效，或执行 FLUSH PRIVILEGES;）
- 永久生效：编辑 /etc/my.cnf 或 /etc/mysql/my.cnf，添加以下内容并重启MySQL服务：
slow_query_log = ON
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 1
log_queries_not_using_indexes = ON（可选，记录未走索引的查询）
如何快速找到真正耗时的SQL
光有日志不够，得靠分析工具提炼重点：
-
mysqldumpslow（MySQL自带）：轻量实用，适合初步筛查
例如：
mysqldumpslow -s t -t 10 /var/log/mysql/mysql-slow.log → 按总耗时排序，取前10条
mysqldumpslow -s c -g "JOIN" /var/log/mysql/mysql-slow.log → 统计含JOIN的语句出现频次 - pt-query-digest（Percona Toolkit）：专业级分析，输出详细统计（平均响应、锁等待、扫描行数、95%分位耗时等），支持聚合与报告生成
- DB-PULSE（可视化工具）：无需Agent，Web界面展示Top慢SQL、执行趋势、扫描行/返回行对比，适合团队协同排查
定位到慢SQL后，下一步怎么分析
不能只看耗时，要深入执行过程：
- 用 EXPLAIN + SQL语句 查执行计划，重点关注：
— type：避免ALL（全表扫描），优先ref/eq_ref/range
— key：是否命中有效索引；possible_keys 是否有可用索引但没被选中
— rows：预估扫描行数，远超结果集数量说明索引效率低或缺失
— Extra：警惕 Using temporary（临时表）、Using filesort（文件排序）、Using where; Using index 是理想状态 - 对关键SQL补充 SHOW PROFILE（需先 SET profiling = 1;），查看CPU、IO、Sorting等各阶段耗时分布，判断是计算瓶颈还是磁盘读写拖慢
- 结合业务场景验证：该SQL是否在高并发时段集中触发？参数是否导致索引失效（如隐式类型转换、函数包裹字段）？
几个容易忽略但关键的细节
实际排查中，这些点常决定优化成败：
- long_query_time 是浮点数，设为1表示“>1.0秒”，0.5秒的查询不会记录；测试时可用 SLEEP(2) 快速验证日志是否生效
- 日志路径权限必须让MySQL进程可写，否则开启失败且无报错提示
- 生产环境慎用 log_queries_not_using_indexes，尤其大流量库，可能日志暴增
- Docker部署时，注意容器内路径（如 /var/lib/mysql/*.slow.log）与宿主机挂载是否一致，否则查不到日志文件
- IN子句含大量值（如 IN(1,2,...,5000)）极易触发慢查询，应考虑改用临时表或分批次处理
