1. “可串行化”的真实定义
用一句话来概括可串行化的核心意义：让“实际交错执行的事务结果”和“这些事务完全排队执行的结果”保持一致。
“串行（Serial）”这个词的物理意义就是排队，一个接一个来。既然是一个接一个，那在任何一个时间点，数据库里都只有一个事务在运行，所以串行执行天然就是“完全无冲突”的。
举个例子，假设有 A、B、C 三个事务：
- 它们可能同时到达数据库。
- 也可能先后到达，但在执行时间上有重叠。
如果我们使用极其严格的加锁方式，强制它们的执行顺序为 A -> B -> C（只有上一个完全结束了，才能启动下一个），这就是严格意义上的“串行执行”。
为什么需要“可串行化”？
实际上，严格的“物理串行”会导致极低的系统吞吐量和效率。为了提高性能，数据库的先驱们提出了一种妥协却精妙的思想：我既想要并发（大家一起上，效率高），又想要串行（绝对安全，不出错）。
由此，“可串行化”诞生了。事务执行的目标变成了：允许事务在物理时间上高度并发执行（允许产生冲突的可能），但通过数据库内部的暗中调控（如锁或 MVCC），确保最终落在磁盘上的数据结果，跟它们从来没有发生过冲突、严格排队执行的结果一模一样。
2. 所有的并发都有对应的“串行结果”吗？这是否意味着事务不能同步执行？
是的，一堆成功提交的并发事务，在逻辑上一定能对应上某一个“串行结果”。但这绝不意味着它们在物理上不能同步执行！
假设你现在扔给数据库 3 个事务：A、B、C。
如果它们“完全隔离、排队串行执行”，理论上有 \(3! = 6\) 种可能的排列组合结果：
A -> B -> CA -> C -> BB -> A -> C- ...依此类推，共 6 种。
这 6 种结果都是绝对合法、绝对正确的“基准标答”。只要你最终这三个事务并发同步执行所产生的真实结果，能够完美契合这 6 种结果中的任意一种，数据库就认为这次并发执行是完美的，即符合“可串行化”。
3. 为什么结果匹配这 6 种里的“任意一种”就行？
很多人的直觉是：如果物理上是 A 先开始、B 后开始，结果不就必须符合 A -> B 吗？
事实上，从数据库引擎的角度看，它并不知道现实世界里的“挂钟时间”。它只看到一堆读写请求像雨点一样打进来。
假设你有两个并发事务：
- 事务 A： 把账户余额加 100。
- 事务 B： 把账户余额翻倍。
如果 A 在 10:00:01 触发，B 在 10:00:02 触发。此时会有两种合法的逻辑顺序：
- 逻辑顺序
A -> B： 结果是 \((余额 + 100) \times 2\)。 - 逻辑顺序
B -> A： 结果是 \((余额 \times 2) + 100\)。
只要数据库最终给出的结果是上述两者之一，它就维持了数据的完整性（Consistency）。对于数据库内部逻辑而言，这两种状态都是绝对合法的，因为它们都代表了数据从“一个原本正确的状态”安全转换到了“另一个正确的状态”。物理上的微小时间差在并发系统中是被弱化的，逻辑上的自洽才是底线。
4. 结合 MySQL 的四种隔离级别来看
理解了可串行化的严苛标准，我们再来看看 MySQL（InnoDB）是如何在“性能”和“一致性”之间做权衡的。
| 隔离级别 | 脏读 (Dirty Read) | 不可重复读 (Non-repeatable Read) | 幻读 (Phantom Read) | 性能 |
|---|---|---|---|---|
| 读未提交 (Read Uncommitted) | 允许 (极危险) | 允许 | 允许 | 极高 |
| 读已提交 (Read Committed) | 禁止 | 允许 | 允许 | 高 |
| 可重复读 (Repeatable Read) | 禁止 | 禁止 | 部分禁止 (通过间隙锁) | 中 |
| 可串行化 (Serializable) | 禁止 | 禁止 | 禁止 | 低 |
1）只有 Serializable 才是真正的“可串行化”
如表所示，MySQL 只有最高级别的 可串行化 (Serializable) 能够百分之百满足我们前文讨论的“可串行化”定义（底层通过强制加锁实现），但它的性能也是最低的。
2）在默认级别（RR）下如何防止非串行化异常？
MySQL 的默认级别是 可重复读（Repeatable Read, RR）。在这个级别下，普通的 SELECT 查询是“快照读（Snapshot Read）”，不加锁。为了防止在并发写时出现“写倾斜”等非串行化异常，最通用的做法是把默认的“快照读”升级为“当前读”。
你可以通过以下两种 SQL 语法显式地告诉数据库：“我要这行数据的控制权”：
A. 排他锁 / 写锁 (FOR UPDATE)
SELECT ... FOR UPDATE;
- 作用： 告诉数据库，我读这行数据是为了修改它。
- 效果： 其他事务既不能改这行数据，也不能再对这行数据加锁。它们必须等你当前事务提交后才能继续。
B. 共享锁 / 读锁 (FOR SHARE)
SELECT ... FOR SHARE;
-
作用： 告诉数据库，我要依赖这行数据做判断，在我用完之前，谁也别想改它。
-
效果： 其他事务可以并行读取这行数据，但绝对不能修改它。