MySQL 查询缓存曾是 DBA 提升读性能的常用手段，但随着版本迭代，它带来的问题逐渐超过收益，最终在 MySQL 8.0 中被彻底移除。本文将从实际运维中遇到的缓存失效问题切入，深入剖析其失效机制，并给出切实可行的替代方案。
查询缓存的工作原理
MySQL 查询缓存（Query Cache）在 5.1 及之前版本中用于缓存 SELECT 语句的结果集。当相同的查询（严格匹配 SQL 文本）再次执行时，直接从缓存返回结果，跳过解析和执行阶段。其核心是哈希表，键为 SQL 语句的哈希值，值为结果集及元数据。
缓存命中需要满足：SQL 语句完全一致（包括大小写、空格、注释），且未使用非确定性函数（如 NOW()）、用户变量等。一旦表数据发生变化，相关缓存条目立即失效。
缓存失效的触发条件
任何对表数据的修改（INSERT、UPDATE、DELETE、TRUNCATE、ALTER 等）都会使该表的所有查询缓存失效。即使是未影响任何行的 UPDATE 也会触发失效。此外，InnoDB 的事务隔离级别也会影响缓存行为。
失效操作是逐表进行的：MySQL 维护一个表级依赖列表，当表数据变更时，遍历并清除所有依赖该表的缓存条目。在高写入场景下，失效操作本身会带来额外的锁竞争和开销。
查询缓存的弊端与废弃原因
查询缓存在高并发读写混合场景下弊大于利。首先，缓存失效需要全局锁保护，导致写入操作阻塞。其次，缓存命中率受限于查询的重复度，若查询多样化，命中率极低。此外，缓存管理本身消耗内存，且无法处理复杂查询（如子查询、分区表等）。
MySQL 官方在 5.7 中已不推荐使用，并在 8.0 中移除该功能。替代方案应运而生，如应用层缓存、代理层缓存等。
替代方案一：应用层缓存（Redis）
最直接的替代方案是在应用层引入 Redis 等缓存中间件。通过缓存查询结果，可显著降低数据库压力。但需注意缓存与数据库的一致性，常见策略包括 Cache-Aside、Read-Through 等。
以 Cache-Aside 为例：读时先查缓存，未命中则查库并回填；写时先更新数据库，再删除缓存。需处理缓存击穿、雪崩等问题，并设置合理的过期时间。
示例如下（Python 伪代码）：
import redis, pymysql
r = redis.Redis()
key = "user:1001"
data = r.get(key)
if not data:
conn = pymysql.connect(...)
data = query_db(conn, "SELECT * FROM user WHERE id=1001")
r.setex(key, 300, data)
替代方案二：代理层缓存（ProxySQL）
ProxySQL 是支持查询缓存的数据库代理，可在不修改应用代码的情况下缓存查询结果。其缓存基于查询指纹，支持按用户、schema 等维度配置。
配置示例：在 ProxySQL 中设置 mysql_query_cache 相关参数，并指定缓存规则。例如，缓存 SELECT 语句且 TTL 为 60 秒。ProxySQL 会拦截请求，若命中缓存则直接返回，否则透传到后端 MySQL。
但需注意，ProxySQL 的缓存同样存在失效问题，且无法感知数据变更，只能依赖 TTL 过期。因此适合读多写少、对实时性要求不高的场景。
替代方案三：使用 MySQL 8.0 的写缓存与读扩展
MySQL 8.0 移除了查询缓存，但提供了其他优化手段。例如，利用 InnoDB 缓冲池缓存数据页，减少磁盘 I/O；通过只读副本分担读负载；使用性能监控工具（如 Performance Schema）定位慢查询。
此外，可考虑使用 MySQL HeatWave 等分析型引擎，或结合外部缓存层（如 Memcached）实现类似效果。
如何选择适合的替代方案
选择缓存方案需考虑以下因素：
- 数据一致性要求：若要求强一致，应用层缓存需谨慎设计；代理层缓存可能返回脏数据。
- 查询模式：重复查询多、读多写少，适合代理缓存；查询多样，则应用层缓存更灵活。
- 运维复杂度：应用层缓存需开发配合；代理层可透明接入，但需额外部署。
- 成本：Redis 集群、ProxySQL 均需额外资源。
实际案例：某电商平台将热门商品信息缓存在 Redis，TTL 设为 10 分钟，配合数据库更新时主动删除缓存，将数据库读压力降低 70%。而另一论坛则使用 ProxySQL 缓存热门版块的帖子列表，效果显著。
常见误区与注意事项
误区一：认为查询缓存是万能的，未考虑写入频率。高写入场景下，缓存失效开销可能超过收益。
误区二：忽略缓存一致性。使用 TTL 过期时，需接受短暂的不一致窗口。
误区三：缓存所有查询。应只缓存高频、低实时性要求的查询，并设置合理的 TTL。
注意事项：监控缓存命中率、内存使用率；定期清理过期数据；在缓存层做好高可用（如 Redis Sentinel）。
参考资料
- OWASP 日志安全速查表 – 关于日志记录的安全最佳实践，可借鉴缓存日志的记录方式。
- OpenTelemetry Logs 官方文档 – 了解日志与可观测性集成，有助于监控缓存性能。
- Python Logging 官方文档 – 示例代码中展示了日志记录，可用于缓存操作的审计。
延伸阅读