先更新数据库再操作缓存，确保数据一致；推荐事务提交后删除或更新缓存，避免回滚导致污染；高并发下可用延迟双删减少旧数据重载风险；复杂系统可结合Binlog或消息队列异步同步缓存；读操作优先查缓存以减轻数据库压力，但强一致性场景应直连数据库；核心是保证事务成功后再处理缓存，缓存仅为加速手段，数据以数据库为准。
在使用 MySQL 事务时，结合缓存可以提升系统性能，但必须注意数据一致性。事务的原子性和缓存的异步特性容易导致脏读或数据不一致。关键在于：先操作数据库事务，再更新或清除缓存，确保缓存状态与数据库最终一致。
1. 先更新数据库，再操作缓存
这是最推荐的做法。在事务提交后，再对缓存进行处理，避免事务回滚导致缓存污染。
- 开启事务，执行写操作（INSERT/UPDATE/DELETE）
- 提交事务
- 事务成功提交后，删除或更新对应缓存键
例如：用户更新个人资料，先更新 MySQL 中的 user 表，事务提交后再删除 Redis 中的 user:123 缓存。下次读取时重新加载最新数据。
2. 使用延迟双删策略防止并发问题
在高并发场景下，可能有请求在事务提交和缓存删除之间读到旧数据并重新写入缓存。可采用“先删缓存 → 提交事务 → 延迟再删一次”的方式降低风险。
- 第一步：删除缓存
- 第二步：执行数据库事务
- 第三步：事务提交后，等待几毫秒，再次删除缓存
适用于缓存穿透或并发更新频繁的场景，如商品库存变更。
3. 结合 Binlog 或消息队列实现缓存同步
对于复杂系统，可通过监听 MySQL 的 Binlog（如使用 Canal）将数据变更异步通知到缓存服务。
- 事务提交后生成 Binlog 记录
- 消息中间件消费变更事件
- 根据事件类型清理或刷新缓存
这种方式解耦数据库和缓存逻辑，适合大型分布式系统，但有一定延迟。
4. 读操作优先从缓存获取
在事务不影响读路径的前提下，查询尽量走缓存，减轻数据库压力。
- 先查缓存是否存在数据
- 缓存未命中时查询数据库
- 将查询结果写入缓存，并设置合理过期时间
注意：事务中的读操作是否绕过缓存取决于隔离级别和业务需求，强一致性场景建议直接查库。
基本上就这些。核心是保证数据库事务成功后再处理缓存，避免数据错乱。缓存只是加速手段，数据源仍以数据库为准。设计时要考虑失败重试、缓存穿透和雪崩等问题。不复杂但容易忽略细节。