MySQL 5.7升级8.0后慢查询突增，主因是slow_query_log默认仅记录已提交事务的慢语句、时间戳格式变微秒、MDL机制重构及optimizer_switch默认变更，需逐项校验配置、日志解析兼容性、执行计划与分位数性能指标。
升级后慢查询突然变多，先确认是否统计口径变了
MySQL 5.7 升级到 8.0 后，slow_query_log 默认行为有变化：8.0 开始默认只记录执行时间超过 long_query_time 且**已提交事务**的语句；而 5.7 对未提交事务的慢语句也会记录。如果你依赖未提交事务的慢日志做分析，升级后会“消失”一部分日志。
- 检查当前实际生效值：
SELECT @@global.long_query_time, @@session.long_query_time;（注意：动态修改后需用SET PERSIST才能重启不丢失） - 确认日志是否包含未提交语句：
SELECT @@global.log_slow_slave_statements, @@global.log_slow_admin_statements;，8.0 新增了log_slow_replica_statements（旧名log_slow_slave_statements），但默认仍为 OFF - 如果应用大量使用长事务，建议显式开启：
SET PERSIST log_slow_replica_statements = ON;
用 pt-query-digest 分析日志前，先校验时间戳格式兼容性
MySQL 8.0 默认日志时间戳格式变为带微秒精度的 # Time: 2024-01-01T12:34:56.123456，而老版本 pt-query-digest（如 3.0.x 之前）可能无法正确解析，导致聚合错乱或跳过大量条目。
- 运行前先测试解析：
pt-query-digest --print --no-report /var/lib/mysql/slow.log | head -20，观察输出中Time字段是否正常、Query_time是否为数值 - 若报错
Cannot parse time或时间显示为0，升级 Percona Toolkit 至 3.5.0+（支持 ISO 8601 微秒格式） - 临时降级兼容：启动 MySQL 时加参数
--log-slow-verbosity=standard（仅 8.0.26+ 支持），可禁用微秒输出
性能验证不能只看 QPS 和平均响应时间
升级后即使 SHOW GLOBAL STATUS LIKE 'Queries' 和 sys.schema_table_statistics 显示整体 QPS 上升，也可能掩盖长尾恶化——比如 99% 延迟从 120ms 涨到 350ms，但平均值只涨了 5ms。
- 必须采集分位数指标：用
performance_schema.events_statements_summary_by_digest查SUM_TIMER_WAIT和COUNT_STAR，自己算 p95/p99（注意单位是皮秒，需除以 10^12） - 对比关键 SQL 的执行计划是否变更：对慢查询 ID 运行
EXPLAIN FORMAT=TREE（8.0 新增），重点关注是否出现Using temporary; Using filesort或扫描行数激增 - 留意 optimizer_switch 变化：8.0 默认开启
hash_join=on和skip_scan=on，某些 join 场景反而退化，可临时关闭验证：SET SESSION optimizer_switch='hash_join=off,skip_scan=off';
真正容易被忽略的是 metadata lock 等待和后台线程行为差异
MySQL 8.0 重构了元数据锁（MDL）子系统，performance_schema.metadata_locks 表结构和语义与 5.7 不同，原来靠 show processlist 查 Waiting for table metadata lock 的方式可能漏掉隐式等待；同时，8.0 的后台线程（如 thread/sql/compress_gtid_table）在高 GTID 写入场景下 CPU 占用更高。
- 查真实 MDL 阻塞链：
SELECT * FROM performance_schema.metadata_locks WHERE OBJECT_TYPE = 'TABLE' AND LOCK_STATUS = 'PENDING';，再关联threads表找 blocking_thread_id - 监控新增线程开销：
SELECT THREAD_NAME, PROCESSLIST_INFO, TOTAL_CPU_TIME FROM performance_schema.threads WHERE THREAD_NAME LIKE '%gtid%'; - 如果升级后出现偶发性连接堆积，优先检查
innodb_deadlock_detect（8.0 默认 ON）是否引发额外开销，可尝试关掉压测对比
