mysql事务隔离级别共四种：read uncommitted允许脏读；read committed解决脏读但存在不可重复读；repeatable read为默认级，通过mvcc保证快照读一致性，间隙锁抑制当前读幻读；serializable强制串行，性能最差。
MySQL 事务隔离级别决定了多个并发事务之间能看到什么样的数据状态，直接影响一致性、性能和并发能力。选错级别可能引发脏读、不可重复读、幻读等问题；设太高又会降低并发效率。核心在于理解每种级别“允许什么”和“禁止什么”，再结合业务场景权衡。
四种隔离级别及其行为边界
MySQL 默认是 REPEATABLE READ（可重复读），但不同级别对并发异常的控制能力差异明显：
- READ UNCOMMITTED（读未提交）：最低级别，事务能读到其他未提交事务的修改。可能出现脏读，基本不用。
- READ COMMITTED（读已提交）：只能读到已提交的数据，解决了脏读，但同一事务中多次读同一行可能结果不同（不可重复读）。
- REPEATABLE READ（可重复读）：MySQL 默认级别。通过 MVCC 实现快照读，保证事务内多次读一致；但范围查询仍可能遇到新插入的行（幻读）。注意：InnoDB 用间隙锁（Gap Lock）在当前读（如 SELECT ... FOR UPDATE）中抑制幻读，但快照读不加锁。
- SERIALIZABLE（串行化）：最高级别，强制事务串行执行。所有 SELECT 都隐式加共享锁，写操作加排他锁。彻底避免并发问题，但并发性能最差，容易锁等待甚至死锁。
常见并发问题怎么产生的
这些现象不是“Bug”，而是特定隔离级别下符合逻辑的行为表现：
DESTOON B2B网站管理系统
下载
DESTOON B2B网站管理系统是一套完善的B2B(电子商务)行业门户解决方案。系统基于PHP+MySQL开发，采用B/S架构，模板与程序分离，源码开放。模型化的开发思路，可扩展或删除任何功能；创新的缓存技术与数据库设计，可负载千万级别数据容量及访问。
- 脏读：事务 A 修改了某行但未提交，事务 B 读到了这个中间状态。只在 READ UNCOMMITTED 下发生。
- 不可重复读：事务 A 第一次读某行值为 100，事务 B 提交更新为 200，A 再次读变成 200。发生在 READ COMMITTED 及以下。
- 幻读：事务 A 查询 name='张三' 的记录有 3 条，事务 B 插入一条新的 '张三' 并提交，A 再次查询发现 4 条。在 REPEATABLE READ 的快照读中会出现；若 A 使用 SELECT ... FOR UPDATE，则 InnoDB 的间隙锁会阻止 B 插入，从而避免幻读。
如何选择合适的隔离级别
没有银弹，需看业务对一致性和性能的要求：
- 日志类、统计类等容忍轻微不一致的场景，可用 READ COMMITTED，减少锁竞争，提升吞吐。
- 金融转账、库存扣减等强一致性要求场景，REPEATABLE READ 是平衡之选；必要时配合 SELECT ... FOR UPDATE + 事务重试机制处理幻读风险。
- SERIALIZABLE 仅建议用于极少数必须绝对顺序执行的逻辑，比如某些幂等初始化操作，且要充分测试锁表现。
- 可通过 SELECT @@transaction_isolation; 查看当前会话级别，用 SET SESSION TRANSACTION ISOLATION LEVEL ... 动态调整，不影响全局配置。
实战中容易忽略的关键点
很多问题源于对“读”的类型理解偏差：
- MVCC 只作用于普通 SELECT（快照读），不作用于 SELECT ... FOR UPDATE / LOCK IN SHARE MODE（当前读），后者会触发行锁或间隙锁。
- UPDATE/DELETE 语句即使没显式加锁，也会先做一次当前读来定位记录，因此也受间隙锁影响——这就是为什么“不存在的记录”也可能被锁住。
- 长事务会拖慢 purge 线程清理 undo log，导致历史版本堆积、磁盘增长、MVCC 性能下降，应尽量缩短事务生命周期。
- 不要依赖默认级别“万事大吉”，尤其从 Oracle 或 PostgreSQL 迁移过来的应用，默认可能是 READ COMMITTED，行为差异会暴露逻辑漏洞。
