mysql升级后慢日志不记录的首要原因是slow_query_log为off、long_query_time仍为默认10秒或log_queries_not_using_indexes被意外开启，需依次执行show variables确认三者状态并按需修正。
不是SQL变慢了，而是日志配置被重置或默认行为变了——升级后 long_query_time 仍为 10 秒、slow_query_log 实际是 OFF，或者 log_queries_not_using_indexes 被意外开启。
检查 slow_query_log 和 long_query_time 是否真生效
MySQL 升级常导致 my.cnf 回退到包管理器自带的默认配置，slow_query_log 很可能已关闭，而你看到的“大量简单查询”其实是旧日志残留，或根本没在记录新查询。
- 执行
SHOW VARIABLES LIKE 'slow_query_log';—— 若返回OFF，说明日志压根没开，当前看到的日志文件可能是升级前写的 - 执行
SHOW VARIABLES LIKE 'long_query_time';—— 升级后若仍是默认10.000000，那SELECT * FROM user WHERE id = 123;这类语句绝不会进日志，除非它真卡了 10 秒以上 - 执行
SHOW VARIABLES LIKE 'slow_query_log_file';确认路径是否可写；若目录不存在或权限不足，日志会静默失败，你以为在记，其实什么都没写
警惕 log_queries_not_using_indexes 被默认打开
某些 MySQL 8.0+ 版本（尤其是从 Yum/Apt 仓库安装的）会在升级后默认启用 log_queries_not_using_indexes，哪怕查询只耗时几毫秒，只要没走索引，就强制记入慢日志——这正是“大量简单查询”突然出现的最常见原因。
- 执行
SHOW VARIABLES LIKE 'log_queries_not_using_indexes';，若返回ON，立刻关掉：SET GLOBAL log_queries_not_using_indexes = OFF; - 该选项对生产环境风险极高：一条无索引的
SELECT COUNT(*) FROM logs;每分钟跑一次，就能撑爆磁盘 - 如确需排查未走索引的语句，仅在测试环境临时开启，并配合
log_throttle_queries_not_using_indexes = 10限流
确认日志文件是否混用了新旧实例
升级过程中若未清理旧日志、也未更新 slow_query_log_file 路径，新实例可能仍在往老文件追加写入——而那个文件里早已有升级前积累的、未清洗的原始日志。
- 用
ls -lh /var/log/mysql/slow.log查看文件修改时间，若最新行时间早于升级时间，说明你在看“历史存档” - 执行
SELECT @@global.slow_query_log_file;，对比实际配置路径与文件系统中正在增长的那个文件是否一致 - 安全做法：升级后手动轮转并重命名旧日志（如
mv slow.log slow.log.pre-8.0.34），再重启 mysqld，确保新日志干净可溯
真正要盯住的不是“为什么简单语句进了日志”，而是“这条语句到底有没有走索引、扫描了多少行”——用 EXPLAIN 验证，别被日志表象带偏。日志只是线索，rows 和 type 字段才是真相。
