mysql的查询缓存错误与禁用查询缓存方法

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 syste

m variable。如果你在 8.0+ 环境看到类似缓存行为，那一定是应用层（如 ORM、连接池、代理）或外部缓存（Redis、ProxySQL）在起作用，和 MySQL 内核无关。

真正容易被忽略的是：很多团队升级到 8.0 后，仍保留着老配置里的 query_cache_* 参数，导致 MySQL 启动失败或跳过整个 [mysqld] 段落——务必清理掉这些残留配置项。