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]段落——务必清理掉这些残留配置项。
