MySQL 数据一致性面试问题

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 + 状态机控制，重复请求不产生副作用
• 设置合理超时与重试机制，并配套人工对账通道，容忍短暂不一致

不复杂但容易忽略的是：一致性不是数据库单方面责任，而是隔离级别、锁机制、应用逻辑、运维策略共同作用的结果。面试时讲清哪一层由谁保障，比背定义更有说服力。