SQL Serializable 隔离级别的谓词锁与死锁检测机制详解-SQL-PHP中文网

Serializable 隔离级别不是更安全，而是主动制造串行冲突：PostgreSQL 用谓词锁检测读写依赖并报错，MySQL 则将所有 SELECT 升级为临键锁导致死锁；二者均非异常而是设计行为，性能代价高，应优先优化访问模式而非盲目升级隔离级别。

sql serializable 隔离级别的谓词锁与死锁检测机制详解

Serializable 隔离级别不是“更安全”，而是主动制造串行冲突

在 PostgreSQL 或 MySQL 中启用 SERIALIZABLE，不是给事务加了一层“保险”，而是告诉数据库：“请模拟串行执行，并在检测到任何可能破坏串行等价性的读写依赖时，直接报错或死锁”。这不是异常，是设计行为。

PostgreSQL 报 ERROR: could not serialize access due to read/write dependencies among transactions —— 这是它主动放弃而非失败
MySQL（InnoDB）报 Deadlock found when trying to get lock —— 它用临键锁把 SELECT 范围也锁死，两个事务只要扫描重叠索引区间（比如都查 WHERE status = 'pending'），就大概率互相等待超时
压测初期不显问题？因为低并发下锁等待被掩盖；一旦 QPS 上去，TPS 断崖下跌、慢查询里满屏 Lock wait timeout exceeded

谓词锁（Predicate Lock）在 PostgreSQL 中怎么“模拟串行”

PostgreSQL 不靠锁住物理行或间隙，而是记录事务“关心什么条件”——比如事务 A 执行了 SELECT * FROM orders WHERE user_id = 123 AND status = 'unpaid'，系统就会记下这个谓词：(user_id=123 ∧ status='unpaid')。后续任何修改该谓词覆盖范围的写操作（如 UPDATE orders SET status = 'paid' WHERE user_id = 123），都会触发序列化检查。

它不阻塞读，但会拦截“可能影响该谓词结果”的写 —— 即便那行数据当前根本不在结果集中
没有索引支撑的谓词（如 WHERE JSON_CONTAINS(meta, '"vip": true')）会导致全表谓词注册，开销剧增
EXPLAIN (ANALYZE, BUFFERS) 看不到谓词锁，但 pg_stat_activity 的 state 字段可能出现 active + wait_event_type = 'Lock' + wait_event = 'PredicateLock'

MySQL 的 SERIALIZABLE 实际等于“所有 SELECT 都自动加 LOCK IN SHARE MODE”

MySQL 并不实现标准谓词锁，而是降级为“所有读都升级成临键锁”。这意味着哪怕你只写 SELECT id FROM users WHERE id = 100，它也会对 (99, 101) 这个间隙加锁；如果没走索引，就是全表加锁。

配置差异：SET TRANSACTION ISOLATION LEVEL SERIALIZABLE 在 MySQL 中全局生效于当前 session 的所有 SELECT，无法局部关闭
常见误用：在分页场景用 SELECT ... LIMIT 10 OFFSET 1000 + SERIALIZABLE → 锁住前 1010 行的间隙，极易被其他 INSERT 阻塞
性能影响：TPS 下降 50%+ 是常态；监控上表现为 Innodb_row_lock_time_avg 方差极大，且 innodb_lock_wait_timeout 触发频率陡升

真正能绕过死锁的，从来不是换隔离级别，而是改访问模式

想防幻读或避免并发更新冲突，硬切 SERIALIZABLE 是最重、最慢、最容易崩的路。现实工程中更有效的做法，是让数据库少猜、少拦、快进快出。

把判断逻辑提到事务外：比如“扣库存前先查是否足够”，改成应用层缓存 + 原子计数器（Redis INCRBY），只在最终落库时用 UPDATE t SET stock = stock - 1 WHERE id = ? AND stock >= 1
用 SELECT ... FOR UPDATE 显式锁住确定要改的行，比隐式谓词锁/临键锁范围小得多；但注意：WHERE 条件必须命中唯一索引，否则照样锁范围
乐观锁不是 SERIALIZABLE 的替代品：它不防止并发读取后各自提交，只保证“最后提交者胜出”。用 version 字段时，必须处理 UPDATE ... WHERE version = ? 返回 0 行的重试逻辑，否则用户点一次下单没反应，再点一次就重复下单

SERIALIZABLE 只适合那种运行时间