开启慢查询日志是定位mysql性能瓶颈最直接有效的方式，需配置slow_query_log、long_query_time等参数，结合explain分析执行计划，并用mysqldumpslow或pt-query-digest工具提升分析效率。
开启慢查询日志是定位 MySQL 性能瓶颈最直接有效的方式。它能帮你快速识别执行时间过长、未走索引或扫描行数过多的 SQL，而不是靠猜测或整体监控指标“盲找”问题。
开启并配置慢查询日志
确保慢查询日志已启用，并设置合理阈值（如 1 秒）和记录条件：
- 在 my.cnf 或 my.ini 中添加或修改以下参数：
slow_query_log = ON
slow_query_log_file = /var/lib/mysql/slow.log
long_query_time = 1.0
log_queries_not_using_indexes = ON（可选，便于发现缺失索引的查询）
min_examined_row_limit = 1000（可选，只记录扫描超 1000 行的语句，减少日志噪音）
配置后需重启 MySQL 或执行 SET GLOBAL slow_query_log = ON; 动态开启（注意：动态设置在重启后失效）。
分析慢查询日志内容
日志中每条记录包含关键信息：执行时间、锁等待时间、扫描行数、返回行数、SQL 语句本身。重点关注：
- Query_time：实际执行耗时，超过 long_query_time 才会被记录
- Lock_time：锁等待时间高，说明存在并发争用（如行锁/表锁冲突）
- Rows_examined 与 Rows_sent 比值极大（如 10000:1），大概率缺少有效索引或用了低效条件
- 语句末尾的 SET timestamp=... 可用于关联业务日志定位具体请求时间点
结合 EXPLAIN 定向优化
对慢日志中高频或耗时最长的 SQL，用 EXPLAIN 查看执行计划：
- 检查 type 字段：避免 ALL（全表扫描），优先 const、ref、range
- 关注 key 和 key_len：是否命中预期索引？长度是否合理（如前缀索引截断）？
- 留意 Extra 字段：Using filesort 或 Using temporary 表示排序/分组未走索引，需优化 ORDER BY 或 GROUP BY 字段
- 对比 rows 预估与日志中 Rows_examined 是否接近，偏差大可能统计信息过期，可执行 ANALYZE TABLE
辅助工具提升分析效率
手动翻日志效率低，推荐组合使用：
- mysqldumpslow：MySQL 自带命令，例如 mysqldumpslow -s t -t 10 /var/lib/mysql/slow.log 统计耗时 Top 10
- pt-query-digest（Percona Toolkit）：更强大，支持聚合分析、生成报告、对比不同时间段、输出建议索引等
- 可视化工具：如 Anemometer（基于 pt-query-digest 结果的 Web 界面），适合团队共享和趋势追踪
不复杂但容易忽略的是：慢查询日志只反映“结果”，必须结合业务上下文（比如某接口在高峰期突增慢查）和执行计划才能准确定位根因。
