MySQL数据一致性需分层保障：事务逻辑一致性靠应用层约束与锁机制；主从复制依赖半同步、GTID及校验工具；分布式场景采用最终一致性+幂等设计。
MySQL 数据一致性是面试中高频考点，核心在于理解“一致性”在不同层面的含义——它既指事务 ACID 中的 Consistency（逻辑一致性），也涉及主从复制、分布式场景下的数据同步保障。回答时需分层说明，避免笼统谈“保证数据不丢”。
事务中的逻辑一致性靠应用层+约束共同保障
MySQL 本身不自动校验业务规则，比如“账户余额不能为负”这类逻辑，需要开发者主动实现：
- 用 CHECK 约束（MySQL 8.0.16+ 支持）限制字段取值范围
- 在事务内用 SELECT ... FOR UPDATE 加行锁，再判断余额是否充足，避免并发扣款超支
- 关键操作写入日志表或发起消息队列，便于事后对账与补偿
主从复制一致性依赖半同步+GTID+校验工具
异步复制默认存在延迟，从库可能读到旧数据。提升一致性需组合策略：
- 启用 semi-sync replication，确保至少一个从库落盘才返回成功
- 开启 GTID，避免因 binlog 位置偏移导致主从错位或跳过事务
- 定期用 pt-table-checksum 检测主从数据差异，配合 pt-table-sync 修复
分布式事务场景下优先用最终一致性+幂等设计
跨库、微服务间无法强一致时，应放弃“实时一致”幻想，转向可落地的方案：
- 用 本地消息表 或 事务消息（如 RocketMQ）确保状态变更与消息发出原子性
- 所有接口实现 幂等性：通过唯一业务 ID + 状态机控制，重复请求不产生副作用
- 设置合理超时与重试机制，并配套人工对账通道，容忍短暂不一致
不复杂但容易忽略的是：一致性不是数据库单方面责任，而是隔离级别、锁机制、应用逻辑、运维策略共同作用的结果。面试时讲清哪一层由谁保障，比背定义更有说服力。
