SQL查询缓存原理说明_SQL缓存命中机制讲解

SQL查询缓存以完全相同的SQL文本（字节级一致）为键直接返回结果，但对大小写、空格、注释、连接参数等极为敏感；含不确定函数、用户变量、临时表等SQL不缓存；任何写操作或结构变更均清空关联缓存；仅适用于读远多于写的静态场景。

SQL查询缓存的核心，是用“完全相同的SQL文本”作为钥匙，直接换回之前算好的结果——不解析、不优化、不执行，秒级返回。但它极其严格，稍有不同就失效，也极易被写操作清空。

缓存怎么判断“完全一样”？

MySQL不做语义分析，只做字节级比对：

• SQL字符串必须逐字符一致：SELECT id FROM users 和 select id from users（大小写不同）不命中
• 空格、换行、注释都算差异：WHERE age > 25 与 WHERE age>25 或带/* 注释 */的版本互不兼容
• 数据库名、客户端字符集、协议版本也参与哈希计算，跨库或改连接参数后同样不命中

哪些SQL根本不会进缓存？

只要结果不可预测或不可复现，MySQL直接跳过缓存环节：

• 含不确定函数：如 NOW()、CURRENT_DATE()、RAND()、UUID()
• 涉及用户变量、临时表、存储过程、触发器、系统表（如 mysql.*）
• 预处理语句（prepared statement）在 MySQL 5.1.17 之前完全不支持缓存
• 结果集超过 query_cache_limit（默认1MB），哪怕只超1字节也不缓存

缓存什么时候悄悄消失？

不是等你查的时候才检查，而是“一动就废”：

• 任何写操作都会触发关联表的全量缓存清除：INSERT / UPDATE / DELETE / REPLACE / TRUNCATE
• 结构变更也一样致命：ALTER TABLE / DROP TABLE / DROP DATABASE / CREATE INDEX
• 事务内修改时，相关缓存从修改开始就失效（即使未 COMMIT）
• MySQL重启后，整个查询缓存清空归零

缓存真的有用吗？看这三点

不是开了就高效，得看场景是否匹配：

• 适合场景：静态配置表、字典表、报表快照类查询；读远多于写（比如读写比 > 10:1）
• 慎用场景：用户行为日志表、订单表、实时状态表——一更新就清空，反而增加锁和碎片开销
• 监控依据：用 Qcache_hits / (Qcache_hits + Com_select) 算命中率，低于30%基本可关

基本上就这些。缓存机制简单粗暴，优势明显但边界清晰——不是万能加速器，而是特定节奏下的性能杠杆。