MySQL 8.0查询变慢主因是旧配置与新机制错配：优化器对子查询更严格导致执行路径变深；buffer_pool_size过小引发大量物理读；严格sql_mode使隐式转换失效索引；performance_schema全开增加CPU开销。
不是所有SQL在MySQL 8.0里都会变慢，但确实有一批原本在5.7跑得还行的查询，在8.0里突然响应拉长、CPU打高、甚至被慢日志反复捕获——问题通常不出在“新版本更差”，而在于旧配置、旧写法和新机制之间的错配。
EXPLAIN FORMAT=TREE 显示嵌套更深、执行路径更复杂
MySQL 8.0 的优化器对子查询、JOIN 和窗口函数的处理逻辑更严格，EXPLAIN FORMAT=TREE 会暴露以前被隐藏的执行层级。比如一个带 IN (SELECT ...) 的语句，在 5.7 可能被自动转成 semi-join 并走索引；到了 8.0，若子查询结果集不可预测，优化器可能退回到 nested loop，导致 rows_examined 暴涨数倍。
- 用
EXPLAIN FORMAT=TREE替代老式 tabular 格式，观察是否出现多层->缩进或materialize节点 - 检查子查询是否含非确定性函数（如
NOW()、RAND()），这会让物化失效，触发重复计算 - 临时改写：把
WHERE id IN (SELECT id FROM t2 WHERE ...)拆成JOIN或用EXISTS，看执行计划是否收敛
innodb_buffer_pool_size 设置过小，Buffer Pool 命中率断崖下跌
8.0 默认启用 innodb_buffer_pool_dump_at_shutdown 和 innodb_buffer_pool_load_at_startup，但若 innodb_buffer_pool_size 还沿用 5.7 时代的 512MB 或 1GB，高并发下 Buffer Pool 很快被刷空，大量物理读涌向磁盘，SHOW ENGINE INNODB STATUS\G 中 “Pages read ahead” 和 “Pages flushed” 数值会异常偏高。
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
- 验证当前值：
SELECT @@innodb_buffer_pool_size / 1024 / 1024 AS mb;，再比对SHOW ENGINE INNODB STATUS里 “BUFFER POOL AND MEMORY” 部分的 “Database pages” 占比 - 合理区间是物理内存的 50%–75%，但必须预留 ≥2GB 给 OS + 其他进程（尤其开了
performance_schema全量采集时） - 若启用了
innodb_buffer_pool_instances > 1（默认为 8），确保innodb_buffer_pool_size是其实例数的整数倍，否则会被向下取整并报 warning
sql_mode 严格化导致隐式转换失败、索引失效
8.0 默认开启 STRICT_TRANS_TABLES 和 NO_ZERO_DATE，当应用传入字符串型条件（如 WHERE status = '1'）而字段是 TINYINT 时，5.7 会静默转成数字比较；8.0 在严格模式下可能拒绝转换或触发全表扫描——因为类型不一致，索引无法使用。
- 查慢日志中是否高频出现
ERROR 1292（截断警告）或ERROR 1366（字符集转换失败） - 用
EXPLAIN看key字段是否为NULL，同时检查type是否退化为ALL或index - 修复方向：应用层统一参数类型（避免字符串传数字字段），或数据库层加函数索引（如
ALTER TABLE t ADD INDEX idx_status_str ((CAST(status AS CHAR))));）
performance_schema 全开拖慢高 QPS 场景
8.0 默认启用全部 performance_schema instruments 和 consumers，包括 events_statements_history_long。在每秒数千次简单查询的场景下，单实例 CPU user 时间可能额外增加 5–15%，且 setup_actors 默认监控所有用户，加剧 mutex 竞争。
- 先确认是否真由它引起：临时关闭
performance_schema（SET GLOBAL performance_schema = OFF;），观察 QPS 和延迟变化（仅限测试环境） - 生产环境应精简配置：禁用非必要 instruments（如
statement/sql/select可留，statement/com/Quit可关），限制consumers仅保留events_statements_current和events_waits_current - 注意：某些云 RDS（如阿里云 PolarDB）不支持运行时关闭
performance_schema，需改配置后重启
真正卡住人的往往不是某一个配置项，而是多个“合理默认值”叠加后的负向共振——比如 buffer pool 小 + performance_schema 全开 + 一堆未走索引的严格模式 SQL，三者一起发力，QPS 就会断崖式下跌。调优时别盯着单点猛踩，优先抓 mysql.slow_log 里 top 5 的查询，结合 sys.statement_analysis 看平均延迟和扫描行数，再逐个切片验证。
