mysql执行SQL会先查缓存吗_SQL缓存命中流程解析

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 写法和执行计划理解——这些才是真正可控、可验证、可长期受益的点。