MySQL慢查询日志默认关闭，需手动配置开启；持久化须修改my.cnf，设置slow_query_log=ON、slow_query_log_file和long_query_time；云数据库需通过控制台开启；分析依赖pt-query-digest工具及日志中Query_time、Lock_time、Rows_examined等关键字段。
怎么打开 MySQL 的慢查询日志
默认关闭，不手动开就永远看不到慢 SQL。关键不是“要不要开”，而是“开在哪”和“开多严”。
- 用
SET GLOBAL slow_query_log = ON可临时开启，但 MySQL 重启后失效 - 持久化必须改配置文件（如
/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf），加这三行：[mysqld] slow_query_log = ON slow_query_log_file = /var/log/mysql/mysql-slow.log long_query_time = 2
-
long_query_time单位是秒，支持小数（比如0.5），但注意：MySQL 5.7+ 默认按微秒精度统计，而该参数仍以秒为单位比较——别误以为设成0.1就能抓到所有 100ms 查询，实际可能漏掉锁等待耗时 - 如果用的是云数据库（如阿里云 RDS、腾讯云 CDB），通常不让你改配置文件，得进控制台开关，并注意日志保留天数和下载方式
慢日志里哪些字段真正有用
日志不是拿来“读”的，是拿来“筛”和“对齐”的。重点盯三个字段：# Time、# User@Host、# Query_time，其余多数可忽略。
-
# Query_time是执行时间，但不含锁等待；# Lock_time才反映行锁/表锁卡多久——两者差很大时，说明问题不在 SQL 本身，而在并发争抢 -
# Rows_sent和# Rows_examined必须对比看：Rows_examined远大于Rows_sent（比如 10 万 vs 10）大概率缺索引或用了LIKE '%xxx' - 注意日志里没有参数值，只有带问号的预编译模板，所以不能直接复现。想定位具体哪条业务调用慢，得结合应用层日志里的 trace_id 或 SQL 绑定参数回填
用 pt-query-digest 快速定位瓶颈 SQL
人工翻日志效率低，pt-query-digest 是目前最稳的分析工具，不是“可选”，是“事实标准”。
- 安装：Debian/Ubuntu 上用
apt install percona-toolkit，macOS 用brew install percona-toolkit - 基础命令：
pt-query-digest /var/log/mysql/mysql-slow.log，默认按Query_time总耗时排序输出前 10 - 关键要看 “Profile” 部分里的
Rank、Response time、Calls和Item—— 排第一的未必最慢，但往往是调用量大+平均慢的组合体 - 加
--filter '$event->{Bytes} > 1024'可过滤只查返回数据多的语句；加--since '2024-06-01 00:00:00'限定时间范围，避免全量扫描拖慢分析
优化前先确认是不是真慢、慢在哪一层
很多“慢查询”根本不是 SQL 的问题，而是网络、连接池、事务设计或缓存穿透导致的假象。
- 用
EXPLAIN FORMAT=JSON看执行计划，重点检查type是否为ALL（全表扫描）、key是否为NULL、rows是否远超预期 - 在从库上查出慢日志？先确认是否主从延迟：执行
SHOW SLAVE STATUS\G看Seconds_Behind_Master，延迟高时从库的Query_time会虚高 - 同一 SQL 在命令行快、应用里慢？大概率是应用没关自动提交（
autocommit=0），导致隐式开启长事务，锁住资源 - 加了索引还是慢？检查字段类型是否一致（比如
user_id是VARCHAR，但代码传的是数字，触发隐式转换，索引失效）
慢查询分析真正的复杂点不在工具链，而在于你得同时看三层：SQL 执行计划、应用调用上下文、数据库运行状态（如 SHOW PROCESSLIST 当前阻塞关系）。少盯任何一层，都容易把锁等待当成执行慢，把缓存雪崩当成索引缺失。
