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%基本可关
基本上就这些。缓存机制简单粗暴，优势明显但边界清晰——不是万能加速器，而是特定节奏下的性能杠杆。
