MySQL事务一致性需协同ACID机制、隔离级别选择与应用层控制：显式开启事务并确保原子提交或回滚；合理选用REPEATABLE READ等隔离级别防并发异常；跨服务场景采用TCC或可靠事件等最终一致性方案；辅以幂等设计、版本校验与备份恢复兜底。
MySQL 中保证事务一致性，核心是正确使用事务机制 + 合理设计隔离级别 + 配合应用层控制。不是单靠某一个功能，而是数据库能力与业务逻辑协同的结果。
用好 ACID 特性，尤其是原子性与持久性
MySQL 默认的 InnoDB 引擎支持完整的 ACID。关键在于显式开启事务、正确提交或回滚：
- 用 BEGIN 或 START TRANSACTION 显式开启事务，避免隐式提交干扰
- 所有相关操作（如扣库存 + 写订单 + 记日志）必须在同一个事务内完成
- 执行成功后用 COMMIT；任一环节失败，立刻 ROLLBACK，不能只靠程序 try-catch 忽略回滚
- 确保 autocommit=0（事务模式），尤其在连接池场景下，避免连接复用导致意外自动提交
选对事务隔离级别，平衡一致性与性能
MySQL 默认是 REPEATABLE READ，适合多数强一致性场景，但要注意幻读问题：
- 读已提交（READ COMMITTED）：避免脏读和不可重复读，适合高并发读多写少场景，但可能引发更新丢失
- 可串行化（SERIALIZABLE）：最强一致性，但锁粒度大、并发低，仅用于极敏感的金融类核对场景
- 不要长期使用 READ UNCOMMITTED，即使“快”，也会读到未提交数据，破坏业务逻辑前提
- 必要时配合 SELECT ... FOR UPDATE 在查询时加行锁，防止并发修改同一记录
跨库/跨服务场景：用补偿事务或最终一致性方案
纯 MySQL 事务无法跨越数据库或微服务边界。此时需跳出单库思维：
- 本地消息表：在同一个库中，先写业务数据 + 写一条状态为“待发送”的消息，再由后台任务异步投递到 MQ，成功后更新消息状态
- TCC 模式（Try-Confirm-Cancel）：将操作拆为三阶段，应用层控制资源预留、确认执行、异常回退
- 可靠事件（Reliable Events）：用 MySQL binlog + Canal / Debezium 捕获变更，推送至下游系统，配合幂等消费保障不重不漏
- 避免“假分布式事务”：比如在两个库上分别 BEGIN-COMMIT，没有全局协调者，本质上不一致风险极高
防误操作与兜底：备份、监控与幂等设计
再严谨的事务逻辑也难防人为失误或极端故障：
- 定期全量 + binlog 增量备份，并实操恢复演练，确保能回到一致时间点
- 对核心资金、库存等表，增加 version 字段或 last_update_time，更新时带上条件（WHERE version = ?），防止覆盖写
- 对外接口强制要求传入唯一业务 ID（如 order_no），服务端用该 ID 做去重判断，避免重复提交导致多次扣减
- 关键事务执行后，补充校验逻辑（如“订单金额 = 商品单价 × 数量”），异常时告警并人工介入
不复杂但容易忽略。一致性不是开关，而是从 SQL 写法、连接配置、服务拆分方式到运维习惯的一整套实践。
