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%';"
返回空结果集，才是干净状态。别让过时配置拖慢你的排查节奏。
