确认慢查询日志是否写入，需执行SHOW VARIABLES LIKE 'slow_query_log'查状态为ON，并核对slow_query_log_file路径可写且正确；再用tail -f实时验证SLEEP(2)查询是否落盘。
如何确认慢查询日志是否正在写入
直接查 slow_query_log 状态和日志路径最可靠，别信配置文件里写了就一定生效。mysql 启动后会按实际加载的配置运行，而配置可能被多处覆盖（比如 my.cnf、my.ini、命令行参数）。
- 执行
SHOW VARIABLES LIKE 'slow_query_log';，返回ON才真在记录 - 同时看
slow_query_log_file值，确认路径是否可写、是否指向你预期的位置（常见坑：指向/var/lib/mysql/hostname-slow.log，但权限不足或磁盘满） - 用
tail -f实时追一下日志文件，发几条带SLEEP(2)的查询，看有没有新内容落盘
关闭慢查询日志的两种有效方式
动态关闭（不重启）和永久关闭（改配置）效果不同，选错会导致下次重启又恢复。生产环境建议两者都做。
- 动态关：执行
SET GLOBAL slow_query_log = OFF;，立刻停止写入，但仅对当前实例生命周期有效 - 永久关：编辑 MySQL 配置文件（如
/etc/my.cnf），删掉或注释掉slow_query_log = 1和slow_query_log_file = ...行，然后重启 MySQL（systemctl restart mysqld） - 注意：如果配置里只写了
slow_query_log没写值，默认是OFF；但若写了slow_query_log = ON或= 1，就必须显式改成= OFF或删掉整行
为什么不能只依赖 long_query_time 调高来“伪装关闭”
把 long_query_time 设成 3600 秒看似能躲过记录，但这是假安全——它只是过滤阈值，日志功能本身仍开启，且存在几个硬伤：
- 某些客户端（如 Percona Toolkit 工具链）会主动读取慢日志文件，不管
long_query_time多大，只要文件存在且可读，就可能被提取分析 -
log_queries_not_using_indexes若为ON，哪怕查询只耗时 0.001 秒，只要没走索引也会进慢日志，完全绕过long_query_time - 日志文件持续增长，占用磁盘，且文件权限若设为 644，其他用户可能直接
cat出敏感 SQL（比如含手机号、身份证的 WHERE 条件）
检查是否还有残留暴露风险
关完日志不等于万事大吉，得验证有没有其他通道仍在输出慢查询上下文。
- 查
SHOW VARIABLES LIKE 'log_output';，如果返回FILE,TABLE或TABLE，说明日志还可能写进mysql.slow_log表，要一并关掉：SET GLOBAL log_output = 'FILE';（再配合关slow_query_log） - 确认
general_log没开——它比慢日志更危险，会记下所有查询，包括认证失败、空连接等，检查语句：SHOW VARIABLES LIKE 'general_log'; - 如果用的是阿里云 RDS、腾讯云 CDB 等托管服务，控制台可能单独开关慢日志，数据库内关了也不代表云平台侧停采集，得去控制台确认
真正难的不是执行那条 SET GLOBAL，而是确认所有配置层、所有输出目标、所有托管侧入口都已切断。漏一处，就可能让一条带用户 ID 的 UPDATE 语句出现在不该出现的地方。
