SERIALIZABLE可串行化会锁表吗

简要结论先给出：

SERIALIZABLE（可串行化）隔离级别“不一定”会锁整张表，但在很多数据库实现中，它比低隔离级别更容易、也更频繁地加锁，且在某些情况下确实会表现为“锁表”或“接近锁表”的行为。

下面分数据库来说明会更清楚。

1. 先说概念：SERIALIZABLE 是什么

SERIALIZABLE 是事务隔离级别中最严格的一级，目标是让并发事务的执行结果等同于某种串行执行顺序。

实现方式通常有两种：

• 锁（Locking）
• 多版本 + 冲突检测（MVCC + 序列化冲突）

不同数据库选的方式不同，所以“会不会锁表”答案不同。

2. MySQL（InnoDB）

结论

InnoDB 的 SERIALIZABLE 通常会加“范围锁 / 间隙锁”，但不是直接锁整张表。

行为特点

• 普通 SELECT 在 SERIALIZABLE 下会隐式变成：

  SELECT ... LOCK IN SHARE MODE
  

• 会加：
  • 行锁
  • 间隙锁（gap lock）
  • Next-Key Lock（行锁 + 间隙锁）
• 如果查询条件无法命中索引：
  • 会锁住大量甚至全表范围的间隙
  • 实际效果“很像锁表”

✅ 所以：

MySQL SERIALIZABLE ≠ 永远锁表
但 无索引查询 + SERIALIZABLE ≈ 锁表

3. PostgreSQL

结论

PostgreSQL 的 SERIALIZABLE 基本不“锁表”，而是用 SI / SSI 机制。

行为特点

• 使用 Serializable Snapshot Isolation (SSI)
• 读不加锁
• 写只在写冲突时失败
• 事务提交时才检测序列化异常

示例：

BEGIN ISOLATION LEVEL SERIALIZABLE;
SELECT ...
UPDATE ...
COMMIT;

如果违反可串行化：

ERROR: could not serialize access due to concurrent update

✅ 所以：

PostgreSQL SERIALIZABLE 不会锁表，而是“重试或失败”

4. Oracle

结论

Oracle 的 SERIALIZABLE 不锁表，靠 MVCC + 回滚段。

行为特点

• 读一致性基于 SCN
• 读不阻塞写，写不阻塞读
• 写冲突时：
  • 后提交的事务报错（ORA-08177）

✅ Oracle SERIALIZABLE 几乎不会锁表

5. SQL Server

结论

可能锁表，取决于设置。

• 默认 SERIALIZABLE：
  • 加范围锁（range lock）
  • 可能升级为表锁
• 若开启 READ_COMMITTED_SNAPSHOT 或 SNAPSHOT：
  • 不锁表

6. 一句话总结表

7. 实践建议

• 不要“为了安全”无脑用 SERIALIZABLE
• 如果必须用：
  • 保证查询有索引
  • 控制事务粒度
  • 考虑用“乐观锁 / 业务重试”替代

如果你能告诉我具体用的数据库 + 场景（读多写少？批量更新？），我可以给你更精确的锁行为分析和替代方案。