mysql数据一致性问题源于事务隔离级别、并发操作与存储引擎特性的交互：repeatable read不防幻读；myisam无事务致丢失更新；主从延迟引发逻辑不一致；应用绕过约束导致隐性错误。
MySQL 数据一致性问题，核心在于事务隔离级别、并发操作与存储引擎特性三者的交互。理解它不靠死记硬背，而要抓住“什么场景下会出错”和“为什么默认没挡住”。
事务隔离级别决定“看见什么”
MySQL 默认的 REPEATABLE READ 隔离级别能避免脏读和不可重复读，但不解决幻读（新插入行导致的前后查询结果集不一致）。比如：事务 A 先查某用户余额为 100 元，事务 B 在此期间插入一笔该用户的支出记录并提交，事务 A 再次查同条件数据时，可能看到多出一条记录——这不是数据被改了，而是“范围视图”变了。
若业务强依赖“绝对一致”的读结果（如金融对账），可考虑：
- 用 select … for UPDATE 加行锁，把读操作升级为写锁，阻塞其他事务对该范围的插入/更新；
- 在必要时临时设为 SERIALIZABLE，但性能代价大，慎用；
- 用 SELECT … LOCK IN SHARE MODE 实现共享读锁，适合只读但需防止被修改的场景。
非事务引擎（如 MyISAM）天然不一致
MyISAM 表没有事务支持，所有 DML 操作立即生效，无回滚能力。即使加了 BEGIN / COMMIT，它也只当作普通语句执行。一旦并发写入（比如两个请求同时 UPDATE 同一行），后写入者会直接覆盖前值，丢失更新。
解决办法很直接：
- 生产环境一律使用 InnoDB 引擎，它是唯一支持完整 ACID 的默认引擎；
- 建表时不显式指定 ENGINE，默认就是 InnoDB（MySQL 5.7+）；
- 迁移老表可用 ALTER TABLE t ENGINE=InnoDB; 转换，注意锁表时间。
主从延迟导致的“逻辑不一致”
主库写入成功后，从库同步有延迟，应用若读从库就可能读到旧数据。这不是 MySQL 本身的数据损坏，而是架构层面的读写分离设计缺陷。
缓解策略包括：
- 关键读操作（如下单后立刻查订单状态）强制走主库；
- 用 GTID + WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS 等待从库追上指定事务；
- 引入中间件（如 ShardingSphere）或应用层做读写分离路由控制，标记强一致性请求。
应用层逻辑绕过约束引发隐性不一致
比如账户余额字段未设 CHECK 约束，又没在应用里校验负值；或用 UPDATE balance = balance – 100 替代先 SELECT 再判断再 UPDATE，看似原子，实则在高并发下可能透支（两条 UPDATE 同时读到 100，都减成 0）。
可靠做法是：
- 数据库层加 CHECK (balance >= 0)（MySQL 8.0.16+ 支持）；
- 用 UPDATE … SET balance = balance – 100 WHERE balance >= 100，让数据库兜底校验；
- 涉及多表或多步的业务逻辑，务必包裹在事务中，并合理设置隔离级别和锁粒度。
不复杂但容易忽略。