mysql查询缓存失效原因_InnoDB与MyISAM缓存机制差异-mysql教程-PHP中文网

mysql查询缓存一更新就全丢，因其采用整表强绑定失效机制：任一表的insert、update、delete、truncate或alter table操作都会清空所有关联该表的缓存条目，不区分sql复杂度或是否涉及修改字段。

mysql查询缓存失效原因_innodb与myisam缓存机制差异

MySQL查询缓存为什么一更新就全丢？

因为MySQL的查询缓存（Query Cache）不是按行、按条件失效，而是「整表强绑定」：只要对某张表执行了 INSERT、UPDATE、DELETE、TRUNCATE，甚至 ALTER TABLE，所有命中过该表的缓存条目——不管SQL多简单、多冷门——瞬间清空。

这不是bug，是设计使然。它用空间换简单性，但代价是高写入场景下命中率趋近于零。

哪怕只改了 user 表里一条记录，SELECT name FROM user WHERE id = 123 和 SELECT COUNT(*) FROM user 的缓存同时失效
ALTER TABLE user ADD COLUMN phone VARCHAR(20) 会触发整个 user 表相关缓存批量清除，不区分是否涉及新字段
MyISAM 和 InnoDB 在这点上行为一致——查询缓存层在存储引擎之上，不感知底层差异

MyISAM 和 InnoDB 的缓存根本不是一回事

别被“缓存”这个词骗了。MyISAM 有 key_buffer_size 缓存索引块，InnoDB 有 innodb_buffer_pool_size 缓存数据页+索引页，而 MySQL Query Cache 是独立第三层，早已在 MySQL 8.0 中被彻底移除。

也就是说：你调大 innodb_buffer_pool_size，对老版本的 Query Cache 完全没影响；反过来，关掉 Query Cache，也不会动 InnoDB 的缓冲池。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

MyISAM 的 key_buffer 只存索引，不存数据；InnoDB 的 buffer_pool 既存聚簇索引也存二级索引，还管理脏页刷盘逻辑
MyISAM 表锁粒度粗，缓存失效后并发读容易排队；InnoDB 行锁 + MVCC，但 Query Cache 失效时照样“一刀切”，不缓解竞争
如果你还在用 MySQL 5.7 或更早，并启用了 Query Cache，SHOW VARIABLES LIKE 'query_cache%' 才能确认它是否真在工作

哪些SQL注定进不了查询缓存？

不是所有合法SQL都能被缓存。MySQL在解析阶段就直接判“缓存免谈”，连进缓存队列的机会都没有。

含不确定函数：比如 NOW()、RAND()、CURRENT_USER()、SYSDATE() —— 缓存了也没意义，下次执行结果不同
访问系统表或临时表：SELECT * FROM mysql.user 或任何 CREATE TEMPORARY TABLE 后的查询都不缓存
结果超限：query_cache_limit 默认 1MB，超过此值的查询结果直接跳过缓存
使用子查询/UNION/视图：即使逻辑简单，如 SELECT * FROM (SELECT id FROM t LIMIT 1) AS tmp，也不进 Query Cache

现在还该用MySQL查询缓存吗？

基本不该。MySQL 8.0 已移除，5.7 官方文档明确标注为「deprecated」，且真实业务中几乎无法稳定受益。

真正有效的缓存，得下沉到应用层或中间件：比如 MyBatis 的二级缓存配合 <cache></cache> 和 useCache="true"，或用 Redis 缓存 user:123 这样的业务键，而不是缓存 SELECT * FROM user WHERE id = 123 这种SQL字符串。