MySQL 的SERIALIZABLE串行化是最高的事务隔离级别。它通过强制事务串行执行来完全避免脏读、不可重复读和幻读但会显著降低并发性能。mysql 串行化隔离级别 指的是所有事务都是串行执行的吗?不是。MySQL 的 Serializable 不是真的串行执行而是用锁来模拟串行效果真正的串行事务A执行完 → 事务B才开始 → 一个一个排队MySQL Serializable事务可以并发但读写互斥效果等同于串行MySQL Serializable 的实际实现InnoDB 的 Serializable Repeatable Read SELECT 自动加共享锁读SELECT→ 自动转为 SELECT … LOCK IN SHARE MODE → 加共享锁S锁写INSERT/UPDATE/DELETE→ 加排他锁X锁并发情况事务A 读 row1 → 加 S 锁事务B 读 row1 → 也加 S 锁 → ✅ 兼容可以并发读事务C 写 row1 → 要加 X 锁 → ❌ 和 S 锁冲突 → 等待A、B释放→ 读读可以并发不是串行→ 读写、写写互斥效果等同于串行核心机制在 InnoDB 中SERIALIZABLE 的实现方式如下自动对普通SELECT加锁所有普通的SELECT语句都会被隐式转换为SELECT ... LOCK IN SHARE MODE共享锁。读取的每一行都会加锁直到事务结束才释放。当前读SELECT ... FOR UPDATE/SHARE、UPDATE、DELETE的行为与 REPEATABLE READ 下一致仍然使用行锁 间隙锁Next-Key Lock。锁冲突导致等待或超时如果一个事务要读取某行而另一个事务正在修改持有排他锁则读取事务必须等待。同样修改操作也必须等待其他事务释放共享锁。与 REPEATABLE READ 的关键区别特性REPEATABLE READSERIALIZABLE普通SELECT快照读无锁基于 MVCC加共享锁当前读并发读-读无阻塞无阻塞共享锁兼容并发读-写读不阻塞写快照读读阻塞写写事务等待读事务释放共享锁并发写-读写阻塞其他写但不阻塞快照读写阻塞读读事务等待写提交幻读处理当前读用间隙锁避免快照读无幻读所有读都是当前读自然无幻读性能较高较低大量锁等待使用场景与注意事项何时使用只有在需要绝对数据一致性且并发极低的场景如财务对账、某些批量操作才考虑使用。多数情况下 REPEATABLE READ 已足够安全。死锁风险增加由于加锁范围更广事务之间更容易形成死锁。如何启用SETSESSIONTRANSACTIONISOLATIONLEVELSERIALIZABLE;-- 或SETGLOBALTRANSACTIONISOLATIONLEVELSERIALIZABLE;默认隔离级别MySQL 默认是 REPEATABLE READ而不是 SERIALIZABLE。简单示例说明阻塞-- 事务 ASETTRANSACTIONISOLATIONLEVELSERIALIZABLE;BEGIN;SELECT*FROMuserWHEREid1;-- 对 id1 的行加共享锁-- 事务 B此时执行会阻塞直到事务 A 提交或回滚BEGIN;UPDATEuserSETnamenewWHEREid1;-- 需要排他锁被 A 的共享锁阻塞总结SERIALIZABLE 通过让所有读操作都加锁来获得最高隔离性但会严重限制并发通常只在对数据一致性要求极高且写入很少的场景下使用。对于绝大多数应用使用 InnoDB 默认的 REPEATABLE READ 即可获得足够的一致性保障。