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的冷启动延迟——它们不会报错，但会让业务在升级后数小时内持续抖动。
