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