MySQL 8.0 起已彻底移除 query_cache 功能，代码层完全删除，SHOW VARIABLES 和 SET 均无效；此前版本缓存命中条件苛刻，实际提速有限，优化应聚焦索引、SQL 写法与执行计划。
MySQL 8.0 及以后版本根本不会查查询缓存
直接说结论：MySQL 8.0 起已彻底移除 query_cache 功能，无论你执行的是 SELECT 还是带函数的复杂查询，服务器压根不走这一步。这不是“默认关闭”，而是代码层删干净了——SHOW VARIABLES LIKE 'query_cache%' 查不到任何相关变量，SET GLOBAL query_cache_size = 1048576 会报错 Unknown system variable。
为什么 MySQL 7.x 以前的查询缓存经常“不生效”
即使你还在用 MySQL 5.7 或更早版本，也别指望它真能提速。缓存命中要同时满足多个苛刻条件：
-
SQL 字符串必须逐字节完全一致：SELECT * FROM user和SELECT * FROM user（末尾多一个空格）算两条不同语句 -
NOW()、CURRENT_DATE、RAND()等非确定性函数会让整条语句被跳过缓存 - 只要对表做了一次
INSERT/UPDATE/DELETE，所有关联该表的缓存项立即失效（不是局部刷新，是全表清空） - 缓存键基于整个 SQL 文本哈希，不识别语义等价，比如
WHERE id=1和WHERE 1=id不会命中同一缓存
真正影响首次查询速度的关键环节其实是解析与优化
没有缓存后，一条 SELECT 进入 MySQL 后的真实路径是：连接器 → 分析器（词法+语法分析） → 预处理器（检查表/列是否存在、权限是否足够） → 优化器（生成执行计划，决定是否用索引、连接顺序等） → 执行器（调用存储引擎读数据）。其中最容易卡住的地方是：
