serializable能彻底防止幻读，因其强制所有操作加范围锁（间隙锁+临键锁），锁住查询范围内的现有行及“尚未存在的插入位置”，实现物理阻塞而非逻辑快照。
Serializable 隔离级别能彻底堵住幻读，但代价是事务串行执行，性能断崖式下降
为什么 Serializable 能解决幻读
它强制所有 SELECT、INSERT、UPDATE、DELETE 操作都加范围锁（gap lock + next-key lock），连“还没存在的记录区间”都锁死。比如 SELECT * FROM orders WHERE created_at > '2026-01-01'，InnoDB 不仅锁住当前匹配的行，还会锁住 created_at 值大于该时间的所有可能插入位置——新事务无法在该范围内插入任何行，自然就不会出现第二次查询多出一条的情况。
这和 RR 级别下 MVCC + 间隙锁的组合不同：Serializable 是“物理阻塞”，RR 是“逻辑快照 + 有限锁定”，后者对非当前读的普通 SELECT 有效，但对 SELECT ... FOR UPDATE 或范围更新仍可能漏锁。
实际开启方式与副作用
设置方式很简单，但影响深远：
- 会话级：
SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE; - 全局级（需 SUPER 权限）：
SET GLOBAL tx_isolation = 'SERIALIZABLE'; - 应用层（如 JDBC）：
connection.setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE);
副作用包括：
- 所有普通
SELECT自动转为SELECT ... LOCK IN SHARE MODE，读操作也排队 - 高并发写入场景下，极易触发
Lock wait timeout exceeded错误 - 主从复制中，串行化事务可能放大延迟，尤其在大事务或慢 SQL 场景下
什么时候才值得用 Serializable
它不是“更安全的默认选项”，而是针对极少数强一致性场景的兜底手段：
- 财务对账类任务：要求两次统计之间绝对不允许任何变更，哪怕只差一行也不行
- 库存预占+扣减闭环：先查剩余量，再扣减，中间不能有新订单插入导致超卖（此时应优先考虑
SELECT ... FOR UPDATE+ 唯一约束） - 审计日志生成：导出某时间段内“最终、不可变”的数据快照，且该过程本身不允许被其他写入干扰
注意：很多所谓“统计数据不准”其实源于业务逻辑没加锁或没用当前读，盲目升到 Serializable 只会让问题从“数据不准”变成“系统卡死”。
比 Serializable 更务实的替代方案
真正线上系统几乎不用 Serializable，常见替代路径是：
- 用
SELECT ... FOR UPDATE显式加锁，配合唯一索引或覆盖索引缩小锁范围 - 把统计逻辑下沉到带版本号的物化视图或汇总表，由定时任务异步更新，避开实时读写冲突
- 改用
INSERT ... ON DUPLICATE KEY UPDATE或REPLACE INTO替代“先查后插”，消除竞态窗口 - 在应用层引入分布式锁（如 Redis Lock）协调关键统计入口，比数据库锁更轻量
Serializable 解决的是理论上的“绝对一致”，但真实业务里，95% 的幻读问题其实在 SQL 写法、索引设计或事务粒度上就有更低成本的解法——锁住不该锁的，比没锁住更危险。
