SQL查询缓存机制_缓存命中与失效分析

SQL 查询缓存是否生效，关键不在“有没有开”，而在于“缓存键是否稳定”和“数据依赖是否被正确追踪”。命中率低通常不是缓存坏了，而是查询结构、参数或数据变更触发了隐式失效。

缓存命中靠的是完全一致的 SQL 文本

MySQL 原生 Query Cache（5.7 及之前）或应用层缓存（如 Redis 存 SELECT 结果），都以标准化后的完整 SQL 字符串为键。哪怕一个空格、注释、大小写或字段顺序不同，都会生成新哈希值。

• ✅ 命中示例：SELECT id, name FROM users WHERE id = 1; 和下一次完全相同的语句
• ❌ 不命中示例：SELECT name, id FROM users WHERE id = 1;（字段顺序变）、select id,name from users where id=1;（大小写 + 空格差异）
• ⚠️ 动态拼接风险：用 Python f-string 或 str.format() 拼 SQL，容易引入不可控空格或换行

哪些操作会立刻清空相关缓存

缓存不是长期有效的快照，而是带依赖关系的临时副本。只要底层数据或结构有变动，关联缓存就强制失效。

• 任意 DML：对表执行 INSERT/UPDATE/DELETE，该表所有缓存条目立即作废（即使事务未提交）
• DDL 变更：ALTER TABLE、DROP INDEX、TRUNCATE 等操作，整张表缓存全清
• 不确定函数：NOW()、RAND()、USER()、SYSDATE() 会让每次查询视为不同语句，无法缓存
• 临时表与用户变量：CREATE TEMPORARY TABLE 或 @var := 1 类语句默认不进缓存

缓存键不一致的常见陷阱

即使业务逻辑相同，ORM 或中间层生成的 SQL 也可能因调用顺序、参数类型、方言差异而不同。

• SQLAlchemy 中：.filter().order_by() 和 .order_by().filter() 生成的 AST 不同，缓存键不同
• 参数序列化问题：字典传参时键顺序不确定（Python 3.6+ 虽保持插入序，但显式排序更稳妥）
• 数字类型混用：WHERE id = '123'（字符串）vs WHERE id = 123（整数），部分方言生成不同 SQL
• 数据库方言差异：PostgreSQL 可能加双引号，MySQL 不加，导致键不匹配

如何验证当前缓存是否真在工作

别只看配置开关，要从运行时指标判断实效性。

• MySQL 原生缓存：查 SHOW STATUS LIKE 'Qcache%';，重点看 Qcache_hits / (Qcache_hits + Com_select) 是否 > 30%
• InnoDB 缓冲池不是查询缓存：用 Innodb_buffer_pool_read_requests 和 Innodb_buffer_pool_reads 算页级命中率，和 SQL 结果缓存无关
• 应用层缓存（如 Redis）：监控缓存 get/set 频次、过期率、miss 后 DB 压力突增情况
• 开启 SQL 日志（如 SQLAlchemy 的 echo=True）：观察相同业务请求是否重复发 SQL