mysql版本升级中的缓存清理与优化建议

MySQL 8.0 移除 query_cache 导致启动失败，需清理配置；innodb_buffer_pool 冷启动致性能下降，应检查 dump/load 配置并手动热载入；performance_schema 内存暴涨需调优 instruments；升级后须执行 ANALYZE TABLE 并建直方图优化执行计划。

MySQL 升级后 query_cache 突然失效或报错

MySQL 8.0 完全移除了 query_cache 相关所有参数和功能，升级后若 配置文件 仍保留 query_cache_type=1 或 query_cache_size=1048576，服务将无法启动，并报错：Unknown system variable 'query_cache_type'。

• 检查升级前的 my.cnf 或 my.ini，删除所有以 query_cache_ 开头的行
• 不要试图通过 SET GLOBAL query_cache_type = 0 关闭它——该语句在 8.0+ 会直接报错
• 应用层若依赖查询缓存行为（比如某些旧 ORM 的“自动缓存 SELECT”逻辑），需改用应用级缓存（如 Redis）或 MySQL 的 SELECT SQL_NO_CACHE …… 已无意义，应一并清理

升级后 innodb_buffer_pool_size 性能不升反降

新版本 InnoDB 对缓冲池管理更激进，默认启用 innodb_buffer_pool_dump_at_shutdown 和 innodb_buffer_pool_load_at_startup，但若升级前未启用 dump、或 dump 文件路径变更 / 权限不足，会导致重启后缓存“冷启动”，QPS 明显下跌。

• 确认 innodb_buffer_pool_dump_at_shutdown=ON（默认 5.7+ 已开启，8.0 默认 ON）
• 检查 innodb_buffer_pool_filename 路径是否可写，且与旧实例一致（例如从 ib_buffer_pool 改为 mysql/ib_buffer_pool 会加载失败）
• 首次升级后可手动触发一次热载入：

  SET GLOBAL innodb_buffer_pool_load_now = ON;

  ，再观察 SHOW STATUS LIKE 'Innodb_buffer_pool_load_status'; 是否完成

MySQL 5.7 → 8.0 升级时 performance_schema 内存暴涨

8.0 默认启用更多 instruments 和 consumers（如 events_statements_history_long），尤其在高并发 OLTP 场景下，performance_schema 自身 内存占用 可达数百 MB，甚至触发 OOM。

• 按需关闭非调试用项：例如设 performance_schema_events_statements_history_long_size=0（默认 20000）、performance_schema_max_sql_text_length=1024（默认 1024，够用）
• 禁用不用的 instruments：

  UPDATE performance_schema.setup_instruments SET ENABLED = 'NO' WHERE NAME LIKE 'statement/sql/%' AND NAME NOT IN ('statement/sql/select', 'statement/sql/insert', 'statement/sql/update', 'statement/sql/delete');

• 注意：修改 setup_instruments 是运行时生效，但重启后恢复默认，需同步写入配置文件中的 performance-schema-instrument 项

升级后慢查询日志中出现大量 Using filesort 或 Using temporary

MySQL 8.0 优化器对索引合并（index merge）、排序算法、窗口函数等行为有调整，部分原 5.7 下走索引覆盖的查询，在 8.0 中因统计信息过期或直方图缺失，改走临时表 +filesort。

• 升级后立即执行：

  ANALYZE TABLE your_table_name;

  ，避免依赖旧版统计信息

• 对高频慢查的字段，主动创建直方图：

  ANALYZE TABLE t UPDATE HISTOGRAM ON c1, c2 WITH 16 BUCKETS;

• 检查执行计划是否用了新引入的 skip_scan，有时反而不如传统 range 扫描高效，可用 /*+ NO_SKIP_SCAN() */ 临时压制

实际升级中最容易被忽略的，是 performance_schema 的隐式内存开销和 innodb_buffer_pool 的冷启动延迟——它们不会报错，但会让业务在升级后数小时内持续抖动。