先更新数据库再操作缓存，确保数据一致；推荐事务提交后删除或更新缓存，避免回滚导致污染；高并发下可用延迟双删减少旧数据重载风险；复杂系统可结合Binlog或消息队列异步同步缓存；读操作优先查缓存以减轻数据库压力，但强一致性场景应直连数据库；核心是保证事务成功后再处理缓存，缓存仅为加速手段，数据以数据库为准。

在使用 MySQL 事务时，结合缓存可以提升系统性能，但必须注意数据一致性。事务的原子性和缓存的异步特性容易导致脏读或数据不一致。关键在于：先操作数据库事务，再更新或清除缓存，确保缓存状态与数据库最终一致。

1. 先更新数据库，再操作缓存

这是最推荐的做法。在事务提交后，再对缓存进行处理，避免事务回滚导致缓存污染。

• 开启事务，执行写操作（INSERT/UPDATE/DELETE）
• 提交事务
• 事务成功提交后，删除或更新对应缓存键

例如：用户更新个人资料，先更新 MySQL 中的 user 表，事务提交后再删除 Redis 中的 user:123 缓存。下次读取时重新加载最新数据。

2. 使用延迟双删策略防止并发问题

在高并发场景下，可能有请求在事务提交和缓存删除之间读到旧数据并重新写入缓存。可采用“先删缓存 → 提交事务 → 延迟再删一次”的方式降低风险。

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• 第一步：删除缓存
• 第二步：执行数据库事务
• 第三步：事务提交后，等待几毫秒，再次删除缓存

适用于缓存穿透或并发更新频繁的场景，如商品库存变更。

3. 结合 Binlog 或消息队列实现缓存同步

对于复杂系统，可通过监听 MySQL 的 Binlog（如使用 Canal）将数据变更异步通知到缓存服务。

• 事务提交后生成 Binlog 记录
• 消息中间件消费变更事件
• 根据事件类型清理或刷新缓存

这种方式解耦数据库和缓存逻辑，适合大型分布式系统，但有一定延迟。

4. 读操作优先从缓存获取

在事务不影响读路径的前提下，查询尽量走缓存，减轻数据库压力。

• 先查缓存是否存在数据
• 缓存未命中时查询数据库
• 将查询结果写入缓存，并设置合理过期时间

注意：事务中的读操作是否绕过缓存取决于隔离级别和业务需求，强一致性场景建议直接查库。

基本上就这些。核心是保证数据库事务成功后再处理缓存，避免数据错乱。缓存只是加速手段，数据源仍以数据库为准。设计时要考虑失败重试、缓存穿透和雪崩等问题。不复杂但容易忽略细节。