升级后慢查询突然变多，先确认是否统计口径变了
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）是否引发额外开销，可尝试关掉压测对比
