MySQL 数据一致性指事务前后数据库始终满足预定义规则（如 CHECK、FOREIGN KEY、UNIQUE），需显式定义约束并配合事务机制；漏事务、缺校验、错隔离级别或禁用外键等任一环节缺失都会破坏一致性。
MySQL 的数据一致性，不是指“数据永远不变”，而是指：在事务执行前后，数据库始终满足预定义的业务规则和约束条件——比如账户余额不能为负、外键引用必须存在、唯一字段不能重复。它不靠 MySQL 自动猜逻辑，而是靠你把规则明确写进数据库（如 FOREIGN KEY、CHECK、UNIQUE），再配合事务机制强制执行。
事务是底线：没事务，谈不上一致性
哪怕 SQL 语法完全正确，只要两条 UPDATE 不在同一个事务里，就可能让数据库卡在“半更新”状态。例如转账：
UPDATE accounts SET balance = balance - 1000 WHERE user = 'A' AND balance >= 1000; UPDATE accounts SET balance = balance + 1000 WHERE user = 'B';这两句如果分开执行，第一句失败、第二句成功，或者中间服务器宕机，都会导致钱凭空消失或出现。必须包在事务里：
START TRANSACTION; UPDATE accounts SET balance = balance - 1000 WHERE user = 'A' AND balance >= 1000; UPDATE accounts SET balance = balance + 1000 WHERE user = 'B'; COMMIT;
- 漏掉
START TRANSACTION或COMMIT，等于裸奔 - 没加
AND balance >= 1000这类前置校验，事务能提交，但业务已出错（一致性被应用层破坏） - 客户端连接断开时未显式
ROLLBACK，可能留下长事务锁表
隔离级别不是越高越好：默认 REPEATABLE READ 已覆盖多数场景
InnoDB 默认的 REPEATABLE READ 能防止脏读、不可重复读，并通过间隙锁（Gap Lock）缓解幻读——对电商库存扣减、订单生成这类核心流程足够用。盲目切到 SERIALIZABLE 会强制行锁升级为范围锁，QPS 可能跌 50% 以上。
-
READ COMMITTED适合高并发只读 + 少量更新场景（如日志归档），但需接受“同一事务内两次SELECT结果可能不同” - 想关间隙锁？可以设
innodb_locks_unsafe_for_binlog=ON，但主从复制下可能丢数据，不推荐 - 用
SELECT …… FOR UPDATE时，即使在REPEATABLE READ下也会加行锁 + 间隙锁，别以为只锁了查到的那几行
约束和触发器是防手抖的最后一道闸
事务保证“全做或全不做”，但不保证“做得对”。比如允许插入 balance = -5000 的记录，事务照样提交成功。这时就得靠数据库级约束兜底：
- 加
CHECK (balance>= 0)（MySQL 8.0.16+ 支持），比应用层判断更可靠 - 外键必须配
FOREIGN_KEY_CHECKS = 1（默认开启），临时关闭后忘了开，就会埋下关联数据断裂隐患 - 触发器慎用：它能自动补字段、校验逻辑，但调试困难、影响写入性能，且主从复制中可能因执行顺序不一致导致数据偏差
真正容易被忽略的点是：一致性从来不是单靠 MySQL 实现的。它需要你在建表时就想好 NOT NULL、DEFAULT、CHECK；写代码时坚持用事务包裹相关 DML；运维时确认 binlog_format = ROW 和 sync_binlog = 1 开启，否则主从延迟或崩溃后，连“已提交”的事都可能回滚。这些环节断掉任何一环，一致性就只是幻觉。
