mysql慢日志默认关闭，需手动配置my.cnf并重启服务才能永久生效；宝塔面板开关无效，必须验证slow_query_log变量状态，确保日志路径权限正确，并用pt-query-digest替代mysqldumpslow分析。

MySQL 慢日志默认是关闭的，必须手动开启

宝塔面板装完 MySQL 后，slow_query_log 默认为 OFF，哪怕你改过配置文件，没重启服务或没生效命令，日志依然不会写。别以为点几下面板就完事了。

实操建议：

• 先登录 MySQL 执行 SHOW VARIABLES LIKE 'slow_query_log'; 确认当前状态
• 临时开启（重启后失效）：运行 SET GLOBAL slow_query_log = 'ON';
• 永久生效必须改配置文件：/www/server/mysql/etc/my.cnf，在 [mysqld] 段下添加或修改以下三项：

slow_query_log = 1
slow_query_log_file = /www/server/data/mysql-slow.log
long_query_time = 2

long_query_time 单位是秒，设成 2 表示超过 2 秒的查询才记；线上环境建议从 1 或 0.5 开始调，否则漏掉很多隐性慢查。

宝塔面板里「数据库」→「性能调整」不能替代配置文件修改

面板里的「慢日志开关」只是个 UI 勾选框，背后没联动写入 my.cnf，也不触发 SET GLOBAL，点了等于没点。常见错误现象：勾选后去查 slow_query_log 变量，发现还是 OFF。

实操建议：

• 别信面板那个开关，它只对部分旧版本宝塔（v7.4.x 以前）有弱作用，新版基本失效
• 改完 my.cnf 后，必须执行 /etc/init.d/mysqld restart 或在宝塔「软件管理」里重启 MySQL
• 重启后立刻验证：mysql -uroot -p -e "SHOW VARIABLES LIKE 'slow_query_log';"

日志路径权限不对会导致 MySQL 启动失败

如果把 slow_query_log_file 设成 /var/log/mysql-slow.log 这类非 MySQL 用户可写的路径，MySQL 会因无法创建/写入日志而拒绝启动，错误日志里会出现 Can't open log file 或直接卡在启动阶段。

实操建议：

• 优先用宝塔默认数据目录：/www/server/data/mysql-slow.log（MySQL 用户天然有权限）
• 如果要自定义路径，先执行 chown mysql:mysql /your/path/ 和 chmod 644 /your/path/mysql-slow.log
• 注意：MySQL 5.7+ 对日志路径校验更严，连父目录不存在都会报错，务必确保路径完整且可写

分析慢日志别只靠 mysqldumpslow，得结合 pt-query-digest

mysqldumpslow 是 MySQL 自带工具，功能弱、解析不准，遇到带变量的预编译语句（如 WHERE id = ?）会把每条都当独立 SQL 统计，结果严重失真。真实场景中，90% 的慢查来自同一类模板，但 mysqldumpslow 看不出来。

实操建议：

• 装 Percona Toolkit：wget https://repo.percona.com/apt/percona-release_latest.$(lsb_release -sc)_all.deb && dpkg -i percona-release_latest.$(lsb_release -sc)_all.deb && apt update && apt install percona-toolkit
• 分析命令示例：pt-query-digest /www/server/data/mysql-slow.log --limit 10
• 重点关注输出里的 Query_time 中位数、Rows_examined 和 ts_col 分布，比单纯看“最慢那一条”有用得多

慢日志本身不产生性能开销，但分析时读全量文件容易卡住，尤其日志超 500MB；上线前先用 head -n 100000 截断再分析，别一上来就硬刚原始日志。