log_slow_admin_statements默认为off，因此alter table等管理语句即使超时也不会记录到慢日志；需显式设为on并确保新连接生效，同时注意long_query_time会话级值、min_examined_row_limit过滤及log_output目标（file或table）影响。
log_slow_admin_statements 默认是 OFF，所以 ALTER TABLE、ANALYZE TABLE、OPTIMIZE TABLE 等管理语句，哪怕执行时间远超 long_query_time，也不会进慢日志。
log_slow_admin_statements 未启用
这是最常见原因。MySQL 8.0 默认不把管理类语句当作“可记录慢查询”对待，哪怕它卡了 30 秒，只要 log_slow_admin_statements = OFF，就直接跳过日志逻辑。
检查方式：
-
SHOW VARIABLES LIKE 'log_slow_admin_statements';—— 返回OFF就是问题所在 - 启用它：
SET GLOBAL log_slow_admin_statements = ON; - 注意：该变量是全局级，但只对新建立的连接生效；已有连接需重连才能看到效果
从库复制语句被误判为“管理语句”
在主从架构中，DROP TABLE 或 CREATE TABLE 这类语句如果由复制线程重放（尤其 binlog_format = ROW），且因 MDL 锁等待导致耗时超标，会被从库记入慢日志——但这不是因为它是管理语句，而是因为 log_slow_replica_statements = ON 且重放过程本身满足慢条件。
关键点：
-
log_slow_replica_statements（8.0.26+）或旧名log_slow_slave_statements必须显式开启 -
ALTER TABLE在从库重放时通常不会触发慢日志，因为它不走相同的语句重放路径（尤其 ROW 格式下是行变更，非原 SQL） - 这类记录容易和真正用户发起的管理语句混淆，排查时要结合
User@Host字段看是否为skip-grants user或replication相关身份
long_query_time 对管理语句也生效，但受会话级影响
即使开了 log_slow_admin_statements，如果当前会话的 long_query_time 是 10，而你执行的 ANALYZE TABLE 耗时 8 秒，它依然不会被记录。
验证当前会话阈值：
-
SELECT @@session.long_query_time;—— 不要只看@@global.long_query_time - 动态修改后必须新建连接，或手动在当前会话 SET：
SET SESSION long_query_time = 0.1; -
min_examined_row_limit同样适用：若设为 1000，而ANALYZE TABLE实际扫描行数不足，也可能被过滤
FILE vs TABLE 输出方式导致“看不见”
如果 log_output = 'TABLE'（MySQL 8.0 默认之一），日志不会写文件，而是插入 mysql.slow_log 表——但这个表可能不存在，或你没查对地方。
确认和修复步骤：
-
SHOW VARIABLES LIKE 'log_output';看输出目标 - 若为
TABLE或FILE,TABLE，检查表是否存在：SHOW CREATE TABLE mysql.slow_log; - 首次启用时，MySQL 不会自动建表；缺失则需手动初始化：
mysql -e "INSTALL PLUGIN slow_log SONAME 'mysqlx.so';"（不推荐）或更稳妥地用mysqld --initialize-insecure初始化后确认，或直接切回FILE方式快速验证 - 云数据库（如阿里云 RDS）常禁用
FILE输出，只支持TABLE，此时必须确保mysql.slow_log可写且结构正确
DROP TABLE，却没注意 User@Host 显示它是复制线程干的——这些细节不核对清楚，就会反复怀疑配置没生效。
