如何排查SERIALIZABLE可串行化问题

在数据库（以 MySQL/PostgreSQL 等关系型数据库为主）中，SERIALIZABLE（可串行化） 是最高的隔离级别，旨在通过严格加锁或冲突检测保证事务“像串行执行一样正确”。但代价是容易引发锁等待、死锁、性能急剧下降，甚至业务逻辑“看起来没问题却跑不通”。

下面从问题表现 → 排查思路 → 具体手段 → 常见根因 → 解决建议系统说明。

一、SERIALIZABLE 常见“问题表现”

1. 事务长时间等待（锁等待）

   • 接口 RT 突然变高
   • 同一张表稍微并发就卡住

2. 死锁（Deadlock）

   • 日志中出现 Deadlock found
   • 事务被回滚

3. 吞吐量骤降

   • QPS 上不去
   • CPU 不高但 TPS 很低

4. 业务逻辑“不符合预期”

   • 读不到“刚写的数据”
   • 重复插入 / 唯一冲突
   • 幻读仍出现（实现不严谨时）

二、排查总思路（非常重要）

先确认“是不是 SERIALIZABLE 引起的”，再确认“为什么需要 SERIALIZABLE”

1️⃣ 确认当前隔离级别

MySQL

SELECT @@transaction_isolation;
-- 或
SHOW VARIABLES LIKE 'transaction_isolation';

会话级

SELECT @@session.transaction_isolation;

PostgreSQL

SHOW transaction_isolation;

2️⃣ 确认事务是否真的在 SERIALIZABLE 下

常见误区：

• 全局是 REPEATABLE READ
• 但某段代码里：

SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;

或框架（Spring）显式指定

✅ 检查：

• ORM 配置
• 数据源配置
• 注解（@Transactional(isolation=...)）

三、核心排查手段

✅ 1. 看锁（最重要）

MySQL：当前锁等待

SELECT * FROM performance_schema.data_lock_waits;
SELECT * FROM performance_schema.data_locks;

查看阻塞关系

SELECT 
  r.trx_id waiting_trx_id,
  r.trx_mysql_thread_id waiting_thread,
  b.trx_id blocking_trx_id,
  b.trx_mysql_thread_id blocking_thread
FROM information_schema.innodb_lock_waits w
JOIN information_schema.innodb_trx b ON b.trx_id = w.blocking_trx
JOIN information_schema.innodb_trx r ON r.trx_id = w.requesting_trx;

当前事务

SELECT * FROM information_schema.innodb_trx;

✅ 2. 看死锁日志（MySQL）

SHOW ENGINE INNODB STATUS;

重点关注：

LATEST DETECTED DEADLOCK

你会看到：

• 哪个事务
• 持有什么锁
• 等什么锁

✅ 3. 慢事务 & 长事务

SERIALIZABLE 下，事务越长越危险

SELECT * 
FROM information_schema.innodb_trx
ORDER BY trx_started ASC;

看：

• trx_started
• trx_state
• trx_query

✅ 4. 应用层日志

重点看：

• 事务开始时间
• SQL 执行顺序
• 是否在事务里做：
  • RPC
  • 睡眠
  • 文件 IO

四、SERIALIZABLE 常见根因（经验总结）

❌ 1. 把 SERIALIZABLE 当“万能保险”

常见问题：

• 怕脏读
• 怕幻读
• 直接上最高级别

✅ 实际上：

• 90% 场景 READ COMMITTED 足够
• 金融核心也常用 REPEATABLE READ + 显式锁

❌ 2. 事务范围过大

@Transactional
public void bigMethod() {
    query();
    rpcCall(); // ❌
    update();
}

SERIALIZABLE 下：

• 锁几乎全程不释放

❌ 3. 读写顺序不一致导致死锁

事务 A：

UPDATE a
SELECT b

事务 B：

SELECT b
UPDATE a

✅ SERIALIZABLE 下极易死锁

❌ 4. 范围查询导致间隙锁（MySQL）

SELECT * FROM order WHERE user_id = 1 FOR UPDATE;

在 SERIALIZABLE：

• 自动加 gap lock
• 不同事务互相等待

五、解决与优化建议

✅ 1. 降级隔离级别（首选）

✅ 2. 缩事务

原则：

事务里只留“必须原子的 SQL”

✅ 3. 固定访问顺序

所有事务：

先 A 后 B

✅ 4. 显式控制并发

• 分布式锁
• 业务幂等
• 版本号 / CAS

✅ 5. 用“乐观并发”替代锁

UPDATE account
SET balance = balance - 10
WHERE id = 1 AND version = 3;

六、一句话总结

SERIALIZABLE 的问题，90% 不是数据库问题，而是“事务设计问题”。

如果你愿意，可以：

• 贴 死锁日志
• 或 事务代码 + SQL
• 或说明 具体业务场景

我可以直接帮你定位是哪一行导致的。