MySQL慢查询日志默认关闭,需手动在/www/server/mysql/etc/my.cnf的[mysqld]段配置slow_query_log=ON、指定slow_query_log_file路径并确保权限,重启服务后用tail -f验证写入。

MySQL慢查询日志默认是关闭的,必须手动启用
宝塔面板本身不自动开启慢查询日志,即使你装了MySQL,slow_query_log 默认值仍是 OFF。直接在面板「数据库」→「配置修改」里改参数没用——改完不重启服务、不验证变量是否生效,等于白改。
实操建议:
- 先登录终端,用
mysql -u root -p进入后执行SHOW VARIABLES LIKE 'slow_query_log';确认当前状态 - 检查日志路径:运行
SHOW VARIABLES LIKE 'slow_query_log_file';,默认可能是/www/server/data/slow-query.log,但该路径可能不存在或无写入权限 - 确保 MySQL 进程用户(通常是
mysql)对日志目录有写权限,否则日志文件创建失败,且不会报错,只会静默失效
在my.cnf中正确配置slow_query_log相关参数
宝塔管理的 MySQL 配置文件路径一般是 /www/server/mysql/etc/my.cnf,不是 /etc/my.cnf。改错位置会导致重启后配置不加载。
在 [mysqld] 段落下添加或修改以下几项(注意不要加引号,布尔值用 ON/OFF 或 1/0 均可,但保持统一):
slow_query_log = ON-
slow_query_log_file = /www/server/data/slow-query.log(建议用绝对路径,且确保父目录存在) -
long_query_time = 2.0(单位秒,支持小数;设为0表示记录所有查询,仅调试用) -
log_queries_not_using_indexes = OFF(慎开,高并发下会急剧增加日志量)
改完必须执行 systemctl restart mysqld(或在宝塔面板「软件商店」→「MySQL」→「重启」),否则配置不生效。
验证慢查询日志是否真实写入
光看 SHOW VARIABLES 不够,得确认日志文件有内容、时间戳在更新。常见假成功现象:变量显示 ON,但日志文件为空或不增长。
快速验证步骤:
- 执行一条明显超时的语句,例如:
SELECT SLEEP(3); - 立刻检查日志文件:
tail -f /www/server/data/slow-query.log - 如果没输出,再查错误日志:
tail -n 20 /www/server/mysql/data/*.err,常会看到类似Could not use /www/server/data/slow-query.log for logging (error 13),即权限问题 - 若仍无效,临时在会话中打开测试:
SET GLOBAL slow_query_log = ON;,再跑SLEEP(3),排除配置加载问题
宝塔面板界面无法实时刷新慢查询日志内容
面板「数据库」→「慢日志」页面只是读取固定路径下的文件,并做简单解析。它不会自动 reload,也不支持过滤或时间范围筛选。实际排查时别依赖这个页面。
更可靠的做法:
- 用命令行实时追踪:
tail -f /www/server/data/slow-query.log | grep -v "admin"(排除宝塔自身健康检查干扰) - 定期归档日志,避免单个文件过大拖慢分析,例如用
logrotate配合mysqladmin flush-logs - 注意
long_query_time是按执行时间判断,不是响应时间;事务中的语句以单条 SQL 计时,不是整个事务
最易被忽略的一点:MySQL 8.0+ 默认使用 error log 的 JSON 格式,但慢查询日志仍是纯文本格式,两者路径和开关完全独立,别混淆 log_error 和 slow_query_log_file。

















