MySQL 8.0+已彻底移除查询缓存，EXPLAIN不再显示缓存相关字段；替代方案是结合EXPLAIN FORMAT=JSON与performance_schema分析执行计划质量与真实运行开销。
MySQL 8.0 及以后版本已彻底移除查询缓存（query_cache_type、query_cache_size 等），所以「查询缓存与执行计划结合使用」这个操作在当前主流 MySQL 中不再成立——不是配置不对，而是功能已不存在。
为什么 EXPLAIN 看不到查询缓存命中？
因为查询缓存被移除后，EXPLAIN 输出中不再有与缓存相关的字段（如旧版的 Extra: Using query cache）。即使你用的是 MySQL 5.7，只要禁用了查询缓存（query_cache_type=0），或语句含不确定函数（NOW()、USER()）、临时表、自定义函数等，缓存也会自动跳过。
-
SELECT必须完全一致（包括空格、大小写、库名是否显式指定）才可能命中缓存 - 任何
INSERT/UPDATE/DELETE修改了相关表，该表所有缓存结果立即失效 -
EXPLAIN本身不触发缓存，它只模拟优化器行为，不走执行路径
替代方案：用 EXPLAIN FORMAT=JSON + 性能模式定位真实瓶颈
既然缓存没了，真正影响响应时间的是执行计划质量与实际运行开销。应转向 performance_schema 和 EXPLAIN FORMAT=JSON 联合分析：
-
EXPLAIN FORMAT=JSON提供used_columns、condition_filtering_pct、rows_examined_per_scan等细节，比传统EXPLAIN更准 - 开启
performance_schema后，查events_statements_history_long可看到某条慢查询的LOCK_TIME、ROWS_AFFECTED、NO_INDEX_USED等真实指标 - 对高频
SELECT，优先检查是否走了索引（type字段是否为ref/range，而非ALL）
EXPLAIN FORMAT=JSON SELECT * FROM orders WHERE user_id = 123 AND status = 'paid';
误配 query_cache_* 参数反而拖慢性能
在 MySQL 5.7 上强行启用查询缓存，常导致更差表现：
- 全局锁竞争：缓存失效时需加全局锁，高并发下成为瓶颈
- 内存碎片：缓存块按固定大小分配，小查询浪费大量空间
- 无法区分冷热数据：哪怕一条查询只执行一次，也占用缓存空间
- 升级到 MySQL 8.0 后若保留旧配置，启动会报错：
Unknown system variable 'query_cache_type'
真正需要关注的是执行计划是否稳定、索引是否覆盖、统计信息是否及时更新（ANALYZE TABLE），而不是试图复活一个已被弃用的机制。
