MySQL的一致性指事务执行前后数据库始终满足完整性约束且业务逻辑正确，由主库事务+约束机制（主键、外键、CHECK等）保障，与主从同步延迟无关。
MySQL中的数据一致性，指的是数据库在事务执行前后始终处于合法、正确、符合业务规则的状态。它不是指“所有节点数据完全同步”，而是强调：任何事务完成之后，数据库必须满足预设的完整性约束（比如主键唯一、外键关联有效、CHECK条件成立），且业务逻辑不被破坏。
一致性是事务的内在要求，不是外部同步结果
很多人把“主从数据一致”等同于MySQL的一致性，这是误解。MySQL的一致性（Consistency）是ACID里的C，它由事务本身保障，核心在于：
- 事务开始前，数据满足所有约束；事务结束后，数据仍满足所有约束
- 即使中间步骤出错（如转账扣了A的钱但没加B的），系统也会通过回滚（ROLLBACK）让数据库回到事务前的一致状态
- 它不依赖复制延迟、网络状况或从库是否跟上——哪怕主从已严重延迟，只要单个事务在主库上正确提交，它就满足一致性
一致性靠约束和事务协同实现
单纯靠事务无法自动识别业务规则，必须配合显式定义的约束机制：
-
主键/唯一约
束：防止重复记录，保证标识唯一性 - 外键约束：确保关联表间引用有效（如订单必须对应真实用户）
- CHECK约束：强制字段取值范围（如age > 0、status IN ('pending','done')）
- 触发器或应用层校验：处理更复杂的跨表逻辑（如库存不能为负）
束：防止重复记录，保证标识唯一性没有这些约束，即使事务成功提交，也可能存入违反业务常识的数据——那就不叫“一致”。
别混淆：一致性 ≠ 强同步，也不等于无延迟
在主从架构中，MySQL默认只能提供最终一致性：从库可能滞后几秒甚至更久。但这不影响主库自身的事务一致性。例如：
- 你在主库执行一个转账事务并COMMIT，主库立刻满足“张三-100、李四+100、总额不变”——这是一致性达成
- 此时从库还没收到binlog，查到的仍是旧余额——这是复制延迟，属于可用性与性能权衡，不破坏主库的一致性语义
- 如果你的应用强制读从库且要求“刚写完就查到新值”，那就需要额外设计（如读写分离路由、GTID等待、或改用强同步复制），但这已超出ACID一致性的范畴
一致性读（快照读）是隔离性带来的副作用，不是一致性本身
像REPEATABLE READ隔离级别下的“一致性读”，本质是MVCC提供的快照能力，目的是避免不可重复读或幻读——它解决的是并发访问时的可见性问题，而非数据是否合法。即使你看到的是旧快照，只要该快照本身满足约束、来自某个已提交事务，它仍然是“一致”的状态。
