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