MySQL 8.0 已彻底移除 Query Cache，所谓“执行计划缓存”并非独立模块，仅存在于 PREPARE/EXECUTE 和存储过程中，且不对外暴露控制接口；误判常源于监控残留、EXPLAIN 确定性输出或 performance_schema 中预处理语句记录。
MySQL 8.0 以后根本没有“执行计划缓存”这回事
直接说结论：MySQL 8.0 已彻底移除 query_cache，而所谓“执行计划缓存”（Execution Plan Cache）并非独立缓存模块，它只存在于预处理语句（PREPARE / EXECUTE）和存储过程中，且不对外暴露控制接口。你看到的“缓存过多”，大概率是误判——真正占用内存、需要干预的是 innodb_buffer_pool 或连接级临时资源。
为什么你会觉得“执行计划缓存太多”？
常见错觉来源：
- 执行
SHOW STATUS LIKE 'Qcache%'发现大量Qcache_hits，但 MySQL 8.0+ 返回空结果或全为 0 —— 这说明查询缓存已不存在，别再查它 - 监控工具显示“Query Cache Memory”非零，其实是旧版插件残留指标，实际无对应内存分配
-
EXPLAIN结果反复一致，误以为“计划被缓存”，实则是优化器对相同 SQL 每次都生成相同计划（确定性行为，非缓存） - 高并发下
performance_schema.prepared_statements_instances表记录数飙升，这才是真正在缓存执行计划的地方，但它不占大内存，且自动管理
真正该清理/调优的三个地方
如果你遇到响应变慢、内存吃紧、SHOW ENGINE INNODB STATUS 显示 buffer pool 压力大，盯准以下三项：
-
清空 InnoDB 缓冲池热点数据：执行
FLUSH TABLES可强制关闭所有表句柄，触发 buffer pool 中对应页的淘汰（注意：不是清空全部，而是按 LRU 清理冷数据）；更激进的做法是重启 mysqld，但生产环境慎用 -
回收预处理语句资源：每个客户端连接持有的
PREPARE语句会缓存解析树和执行计划，长期不DEALLOCATE PREPARE会导致prepared_stmt_count持续增长。建议应用层显式释放，或设置max_prepared_stmt_count限制 -
检查并缩小会话级缓冲区：
sort_buffer_size、join_buffer_size、read_buffer_size是每个连接独占的，若并发连接数高（如 >500），即使设为 2M 也会吃掉 1GB+ 内存。应设为 256K–512K，并配合wait_timeout缩短空闲连接存活时间
别碰这些“伪缓存命令”
很多文章还在教：RESET QUERY CACHE、FLUSH QUERY CACHE、调 query_cache_size……这些在 MySQL 8.0+ 中要么报错 Unknown system variable 'query_cache_size'，要么静默忽略。硬执行只会浪费一次 round-trip，还可能误导运维判断。
真正容易被忽略的是：InnoDB 缓冲池的冷热分离机制（innodb_old_blocks_pct）和预热策略（innodb_buffer_pool_dump_at_shutdown / innodb_buffer_pool_load_at_startup）。如果刚重启就慢，不是“缓存没清干净”，而是“缓存还没热起来”。
