MySQL 8.0 已彻底移除查询缓存，5.6/5.7 中因其基于SQL文本哈希、忽略语义差异与运行时上下文等设计缺陷，极易导致错误结果或性能下降，应全局禁用。
MySQL 查询缓存（Query Cache）在 5.7 版本中已显疲态，8.0 版本直接移除；即使在 5.6/5.7 中开启，也极大概率引发「缓存命中但结果错误」或「缓存失效频繁导致性能反降」的问题。这不是配置不对，而是设计缺陷——它基于 SQL 文本做哈希匹配，不感知表结构变更、权限变化、甚至不区分 SELECT * FROM t 和 SELECT id FROM t 这类语义差异。
为什么查询缓存会返回错误结果
根本原因是缓存键仅依赖 SQL 字符串 + 当前数据库名 + SQL_MODE 等有限上下文，而忽略以下关键因素：
-
SQL_CACHE/SQL_NO_CACHE提示被部分客户端或中间件静默忽略，导致本该绕过的查询进了缓存 - 同一张表被多个线程并发更新时，缓存仅在第一次写入后失效，后续写入若未触发完整 invalidation（如通过
INSERT ... ON DUPLICATE KEY UPDATE），旧缓存仍可能被返回 - 使用了用户变量（
@var）、临时表、FOUND_ROWS()、USER()、NOW()等非确定性函数的查询，缓存后再次执行会返回过期或错误值 - 分区表、InnoDB 全文索引表、或者开启了
query_cache_wlock_invalidate=OFF时，锁机制与缓存清理不同步，造成脏读
如何确认查询缓存正在干扰你的查询
不要只看 SHOW VARIABLES LIKE 'query_cache%' —— 那只告诉你“是否启用”，而非“是否生效”。真正要查的是运行时行为：
- 执行
SELECT SQL_NO_CACHE COUNT(*) FROM information_schema.TABLES后再执行带缓存的同语句，对比SHOW STATUS LIKE 'Qcache_hits'是否增加 - 用
SELECT @@session.sql_cache_mode检查当前会话实际缓存策略（可能被SET SESSION query_cache_type = 0覆盖） - 观察慢查询日志中是否出现
Query_cache_miss_with_lock或Qcache_lowmem_prunes > 0持续增长，这是缓存频繁踢出的信号 - 对一个刚
UPDATE过的行执行相同SELECT，用SELECT NOW(), SLEEP(1), (SELECT ...)验证是否返回旧值
彻底禁用查询缓存的正确方式（5.6/5.7）
光设 query_cache_size = 0 不够：MySQL 仍会分配元数据结构并尝试管理缓存块。必须组合关闭三个开关：
SET GLOBAL query_cache_type = 0; SET GLOBAL query_cache_size = 0; SET GLOBAL query_cache_limit = 0;
并在配置文件 my.cnf 中固化（否则重启失效）：
[mysqld] query_cache_type = 0 query_cache_size = 0 query_cache_limit = 0
注意：query_cache_type=0 是强制关闭，比 =1（按需）或 =2（仅带 SQL_CACHE 的语句）更彻底；且必须用 GLOBAL 级别设置，SESSION 级别无法禁用全局缓存逻辑。
MySQL 8.0 及以后无需手动禁用
查询缓存模块已被完全删除，相关系统变量（如 query_cache_size）已不存在，任何试图设置它们的操作都会报错 Unknown system variable。如果你在 8.0+ 环境看到类似缓存行为，那一定是应用层（如 ORM、连接池、代理）或外部缓存（Redis、ProxySQL）在起作用，和 MySQL 内核无关。
真正容易被忽略的是：很多团队升级到 8.0 后，仍保留着老配置里的 query_cache_* 参数，导致 MySQL 启动失败或跳过整个 [mysqld] 段落——务必清理掉这些残留配置项。
