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 后的真实路径是：连接器 → 分析器（词法+语法分析） → 预处理器（检查表/列是否存在、权限是否足够） → 优化器（生成执行计划，决定是否用索引、连接顺序等） → 执行器（调用存储引擎读数据）。其中最容易卡住的地方是：
- 分析器报错如
ERROR 1064 (42000)：通常是你少了个逗号、引号没闭合，或用了保留字当字段名（比如order） - 优化器选错执行计划：比如本该走
idx_user_id却全表扫描，常见于统计信息过期（可运行ANALYZE TABLE user更新） - 执行器权限不足：报
ERROR 1142 (42000): SELECT command denied，注意这不是连接器阶段拦下的，而是执行前最后一道校验
想提速？别惦记缓存，盯紧这三个地方
缓存删了反而是好事——逼你直面真实瓶颈。实际优化时优先检查：
-
EXPLAIN输出里的type是否为ALL（全表扫描）、key是否为NULL（没走索引） - 慢查询日志是否开启：
slow_query_log = ON，long_query_time = 1，然后用mysqldumpslow或pt-query-digest分析 - 连接是否复用：应用层用
druid或HikariCP管理长连接，避免频繁握手开销；别在代码里写mysql_close()后又立刻mysql_connect()
缓存机制的消亡不是倒退，而是把性能责任交还给索引设计、SQL 写法和执行计划理解——这些才是真正可控、可验证、可长期受益的点。
