mysql 8.0升级后innodb_buffer_pool_size更关键，因innodb成唯一默认引擎且buffer pool新增缓存数据字典等元数据，建议设为内存75%且≥2gb；否则易刷脏页、触发降级、预热失效。
MySQL 8.0 升级后 innodb_buffer_pool_size 为什么更关键了
因为 InnoDB 成为绝对默认引擎，且 Buffer Pool 现在承担更多元数据缓存（如数据字典、DDL 日志），旧配置下容易出现“明明内存充足，却频繁刷脏页”的现象。
- 建议值从“物理内存的 50%–70%”收紧为“至少 75%，且必须 ≥ 2GB”——低于 2GB 会触发隐式降级行为，导致查询计划不稳定
- 若启用了
innodb_buffer_pool_chunk_size（MySQL 5.7+ 引入），需确保innodb_buffer_pool_size是它的整数倍，否则启动时会被静默向下取整，实际分配比预期小 - 升级后首次启动，InnoDB 会预热（
innodb_buffer_pool_load_at_startup=ON），但若innodb_buffer_pool_dump_at_shutdown上次未成功执行（比如崩溃退出），预热文件为空，此时该参数无效
慢查询日志开关和格式变化：从 slow_query_log_file 到 log_error 合并
MySQL 8.0 默认将慢查询日志写入错误日志（log_error），不再单独输出到 slow_query_log_file，除非显式关闭 log_error_verbosity=3 并启用 log_output='FILE'。
- 检查是否真在记录慢查：
SELECT @@slow_query_log, @@log_output, @@log_error_verbosity; - 若想恢复独立慢查文件，必须同时设置：
SET GLOBAL slow_query_log = ON;、SET GLOBAL log_output = 'FILE';、SET GLOBAL long_query_time = 1.0;（注意：8.0 中long_query_time支持微秒精度，但单位仍是秒） - 旧版中靠
mysqldumpslow解析文本日志，8.0 推荐改用performance_schema.events_statements_summary_by_digest查实时聚合指标，避免 I/O 和解析开销
optimizer_switch 默认值变更导致执行计划突变
MySQL 8.0 默认开启 hash_join=on、skip_scan=on、materialization=on，这些优化器特性在某些 JOIN 或子查询场景下反而让计划变差，尤其当统计信息陈旧或字段选择性极低时。
- 典型症状：
EXPLAIN FORMAT=TREE显示HashJoin节点，但实际执行耗时翻倍；或Using temporary; Using filesort消失，但Rows_examined暴涨 - 临时回退方法（按需关闭）：
SET SESSION optimizer_switch='hash_join=off,skip_scan=off'; - 长期方案：升级后必须运行
ANALYZE TABLE，且对高频慢查字段补全直方图（ANALYZE TABLE t UPDATE HISTOGRAM ON c1, c2;），否则优化器无法准确估算skip_scan的收益
Performance Schema 表结构变更影响慢查归因
8.0 中 events_statements_history_long 默认只保留 1000 行，且 digest_text 字段被截断（默认 1024 字节），导致无法还原完整 SQL，误判“相同 digest 不同语义”。
- 调整前先确认容量：
SELECT * FROM performance_schema.setup_consumers WHERE NAME LIKE '%statements%'; - 增大历史表长度：
UPDATE performance_schema.setup_actors SET EVENT_NAME = 'statement/sql/select' WHERE HOST = '%';不起作用——正确方式是修改配置文件中的performance_schema_events_statements_history_long_size=10000 - 若依赖
digest做聚合分析，务必同步开启performance_schema_digests_size（默认 2000，建议调至 10000），否则高并发下 digest 缓存碰撞率飙升，不同 SQL 被合并成同一 digest
升级后最易忽略的是统计信息与直方图的滞后性——哪怕 buffer pool 调得再大、慢日志开得再全，只要 INFORMATION_SCHEMA.STATISTICS 里的 CARDINALITY 还是升级前的值，优化器就大概率选错索引。别急着调参，先跑一遍 ANALYZE TABLE，再看执行计划。
