mysql执行SQL会先查缓存吗_mysql缓存查询流程说明

MySQL 8.0+ 已彻底移除查询缓存功能，不再支持 query_cache_type 等变量，配置即报错；5.7 起该功能已被弃用，且因高失效率和严苛命中条件实际无效；应改用应用层缓存、ProxySQL 或 InnoDB 缓冲池等现代方案。

MySQL 8.0 及以后版本根本不会查查询缓存

直接说结论：如果你用的是 MySQL 8.0 或更新版本（当前已是 2026 年，绝大多数生产环境已升级），query_cache 功能已被彻底移除，执行 SELECT 时压根不存在“先查缓存”这一步。任何文档或教程若未注明版本就讲“查询缓存命中”，大概率过时或误导。

• MySQL 5.7 是最后一个支持查询缓存的稳定版，且从 5.7.20 开始已标记为 deprecated（不推荐使用）
• MySQL 8.0.0 正式删除了所有相关系统变量，如 query_cache_type、query_cache_size，启动时若配置它们会报错
• SHOW VARIABLES LIKE 'query_cache%' 在 8.0+ 中查不到任何结果，不是“关闭了”，而是“没了”

为什么 老版本的查询缓存实际很少生效

即使你还在用 5.7，也几乎不可能靠它提升性能——它太“娇气”了。缓存失效条件极其宽松，导致命中率常年趋近于零。

• 只要表发生任意写操作（INSERT、UPDATE、DELETE、ALTER TABLE），该表所有缓存条目立即清空
• SQL 字符级完全一致才可能命中：多一个空格、少一个分号、注释位置不同、大小写差异（取决于 SQL mode），都会导致 KEY 不匹配
• 含不确定函数的语句不进缓存，比如 NOW()、RAND()、USER()、LAST_INSERT_ID()
• 事务中修改过的表，在事务提交前，其缓存对所有会话都不可用（InnoDB 行为）

替代方案：别依赖 server 层缓存，改用更可控的手段

真正有效的缓存，从来不在 MySQL server 层里做。与其折腾已淘汰的 query_cache，不如把精力放在更现代、更灵活的位置：

• 应用层缓存 ：用 Redis 或 Memcached 缓存 热点 查询结果，键可自定义（如 user:profile:123），过期策略、穿透保护、批量预热都由你掌控
• 客户端连接池缓存 ：如 HikariCP 的 connection-test-query 或 MyBatis 的二级缓存， 作用域 明确、生命周期可控
• 数据库代理层缓存：如 ProxySQL 支持基于规则的 SELECT 结果缓存，支持 TTL、自动剔除、读写分离联动
• 操作系统 页缓存：InnoDB 的 innodb_buffer_pool_size 才是真正的“热数据加速器”，它缓存的是数据页而非 SQL 结果，更底层、更稳定、更高效

验证你是否误启用了已失效的缓存配置

如果你在 配置文件（如 /etc/my.cnf）里还留着 query_cache_type=1 这类配置，MySQL 8.0 启动时会直接拒绝加载，并报类似错误：

mysqld: [ERROR] Found option without preceding group in config file /etc/my.cnf at line 42! mysqld: [ERROR] Fatal error in defaults handling. Program aborted!

正确做法是：删掉所有以 query_cache_ 开头的配置项，再重启 mysqld。运行以下命令确认无残留：

mysql -e "SHOW VARIABLES LIKE'query_cache%';"

返回空结果集，才是干净状态。别让过时配置拖慢你的排查节奏。