各位好，我是路远。搞了十五年数据库，我最怕听到的话就是"这个很简单"。

上周三上午十点，业务高峰，开发一个电话打过来：路哥，库死了。我登录一看就愣住了，CPU、IO、内存全都正常，业务就是卡住不动，页面转圈，订单下不了。这种比CPU打满还难搞。资源都闲着，说明不是在算，是在等。

## 第一现场：会话全在等锁

我先拉活动会话，看大家都在等什么：

```sql
SELECT sid, event, wait_class, seconds_in_wait, sql_id
FROM v$session
WHERE status = 'ACTIVE' AND wait_class <> 'Idle'
ORDER BY seconds_in_wait DESC;
```

结果出来，几十个会话全排在两个等待事件上，`enq: TX - row lock contention`和`enq: TM - contention`。行锁、表锁，全是锁。CPU不忙，是因为根本没有活可干，大家都在等别人放行。

enq 是 enqueue 的缩写，Oracle 的锁排队机制。光看事件名还不够，我把 v$session_wait 的 p1raw、p2 也拉出来看了一眼，确认排的是 TX 队列里哪个资源。干这行久了养成个习惯，等待事件一定要拆到参数层，不然容易被名字带偏：

```sql
SELECT sid, event, p1raw, p2, p3, seconds_in_wait
FROM v$session_wait
WHERE event LIKE 'enq:%' AND state = 'WAITING';
```

这里要先纠正一下。开发兄弟喊的是"死锁了"，但这真不是死锁。死锁是数据库自动检测、自动回滚的，系统不会这么安静地卡住。几十个会话集体排队等一个东西，这叫阻塞链。

## 顺着阻塞链往上摸

要解阻塞，得先找源头，谁拿着锁不撒手，问题就在谁身上。Oracle 10g 往后，v$session 自带 BLOCKING_SESSION 字段，能直接看到阻塞者是谁，比手工 join 省事。但我想看锁的模式和排队情况，还是把 v$lock 拉出来。我查锁的持有关系：

```sql
SELECT b.sid blocking_sid, b.username, b.status,
       a.sid blocked_sid, a.type, a.id1, a.id2, a.lmode, a.request
FROM v$lock a, v$session b
WHERE a.block = 1 AND b.sid = a.sid
ORDER BY b.sid;
```

输出很干净，一个SID把后面几十个会话全堵死了：

```
BLOCKING_SID  USERNAME   STATUS    BLOCKED_SID  TYPE  LMODE
------------  ---------  --------  -----------  ----  -----
287           APPOINT     ACTIVE    31           TX    6
287           APPOINT     ACTIVE    42           TX    6
287           APPOINT     ACTIVE    55           TX    6
...
```

287，就这一个。我顺着看它到底在干嘛：

```sql
SELECT sid, sql_id, event, last_call_et, machine, module
FROM v$session WHERE sid = 287;
```

结果有点尴尬。event是SQL*Net message from client*，last_call_et已经2400多秒。它不干活，正等着客户端下一条指令，手里却攥着一把锁不放。一笔事务攥着锁不撒手，会话已经40分钟没有新动作。不提交也不回滚，就这么挂着。

我翻出它的SQL_ID，调出最后执行的语句，是一句UPDATE。问题出在WHERE条件上，没走索引，等于把整张表的状态字段都划拉了一遍，锁的范围就是整张表。后面的订单插入、状态更新，全堵在这把锁上。

## 根因：一个长事务，一把扫全表的锁

根因其实不复杂，两层问题叠在一起。

第一层，锁范围过大。这里多说一句，Oracle 的 UPDATE 锁的是行，不是表。DML 执行时，先在数据块的 ITL（事务槽）里登记一笔事务，再给命中的行头打上锁标志。走索引，锁的只有命中的那几行。WHERE 条件没走索引，优化器全表扫，每一行都要过一遍条件，命中的行全打上锁。这张表几百万行，更新的是状态字段，命中率几乎百分之百，行锁就从几行膨胀到全表行数。表上还会拿一个 TM 锁，SX 模式，防 DDL 用的，不是业务卡住的元凶。后面再来的会话想改同一行，只能排队。要是走了索引，只锁命中的那几行，后面该干嘛干嘛。

第二层，长事务不提交。应用改完状态，又挂了一段业务逻辑，事务迟迟不关。前端用户以为卡死了，其实数据库在等应用放行。这段逻辑一卡，整条链全堵上。

动手之前我确认了一件事，这笔事务能不能放弃。查了v$transaction，undo使用正常，没跨安全边界，可以安全处理。然后跟业务确认，这笔40分钟的更新可以不要了，才决定kill。

## 止血：kill一个会话，全库喘过气

```sql
ALTER SYSTEM KILL SESSION '287,12345' IMMEDIATE;
```

kill完我盯着监控，活动会话肉眼可见往下掉，排队的那几十个会话陆续拿到锁，2分钟内业务恢复正常。CPU、IO从头到尾没上来过，全程都是锁的事。

说句实话，这单最险的不是技术，是我差点跳步。我第一时间想过先kill再说，最后还是忍住了，先确认业务影响。要是这笔40分钟的事务刚好卡在关键数据上，kill完数据错乱，就是二次事故。先问清楚能不能放弃，再动手。这次排的是阻塞，但开发兄弟喊的是“死锁了”。趁这个机会把这两个概念掰开说清楚，以后遇到类似情况不至于误判。

## 死锁和阻塞，别混为一谈

这次排的是阻塞。趁这机会把两个概念掰开，很多兄弟分不清，真出事了容易误判。

阻塞是单方向排队。A握着锁不撒手，B、C、D在后面干等，数据库不干预，就这么等着。要不要解除，取决于源头提交、回滚，还是DBA动手kill。这次处理的就是这个。

死锁是循环等待。A等B，B等A，谁都不让。这种数据库会自动检测，挑一个牺牲者回滚，抛ORA-00060，剩下的那个继续跑。我在alert log里翻过不少死锁trace，长这样：

```
Deadlock graph:
                       ---------Blocker(s)--------  ---------Waiter(s)---------
Resource Name          process session holds waits  process session holds waits
TX-000e0009-00000480        14     287     X          22      42           X
TX-0009000f-0000042e        22      42     X          14     287           X
```

两个事务互相握着对方要的资源，都在等，数据库检测到这个环，回滚其中一个，释放出锁，另一个才跑完。整个检测、回滚是自动的，不用DBA介入。所以真正的死锁反而好办，数据库自己就处理了；难缠的是阻塞，它不报错，就是让你整个系统干等。

死锁的成因，十有八九是应用里两条路径更新资源的顺序不一致。一条路径先改订单再改库存，另一条先改库存再改订单，并发一上来，两个事务各拿一把锁，等对方手里的，死锁环就形成了。数据库后台有张 wait-for graph 在盯，检测到环就挑代价小的一边回滚。所以遇到死锁，别光看 trace 骂数据库，顺着 trace 里的 SQL 回业务代码，把更新顺序统一，死锁自然就没了。阻塞恰好相反，它没有环，就是一根筋排队，数据库不主动干预，只能靠人工发现。

## 从一次阻塞，看并发设计

这单处理完，我盯着当天的等待曲线想了很久。锁竞争的本质，是并发控制粒度的问题。数据库的锁机制没有错，错在应用把并发压力全压到了数据库身上。

长事务是 OLTP 的隐形杀手。一个事务从开始到提交，中间握着的锁就是它欠下的并发债，事务越长债越重，高峰一碰撞就是连锁反应。设计上事务边界要短，更新路径要短，能走索引绝不扫全表。

热行争用是另一类坑。库存表就一条汇总行，所有订单都来更新这一行，并发一高必然排队。架构上要么拆行，按仓库、按商品拆成多条，要么异步扣减，把写冲突分散开。这次是整表范围的锁，本质也是把写冲突集中到了一个点上。

这套经验往国产数据库上搬的时候要留个心。Oracle 和 MySQL 的锁模型不一样，MySQL 是 record lock 加 gap lock，还有 next-key lock，等待事件的名字也不同。但定位思路是通用的，先找等待，再找阻塞者，再拆根因。我在国产库上排过类似的锁问题，命令换成 information_schema 的几张表，思路一模一样。

## 避坑清单

复盘完这单，我在系统上立了几条规矩，各位可以对照自己环境看看。

上线前确认UPDATE/DELETE的WHERE条件走了索引，锁的范围取决于扫描范围。根因分析里已经讲过原理，关键是养成看执行计划的习惯。

应用层要设锁等待超时。Oracle里FOR UPDATE可以加WAIT，MySQL有innodb_lock_wait_timeout，JDBC也有lockTimeout。超时了就让应用报错，别让用户页面无限转圈，也别让问题憋到没人发现。

出问题先分清是死锁还是阻塞。死锁数据库自己处理了，翻alert log看trace就行；阻塞才需要你动手，先找BLOCK=1的会话，顺着链摸源头，摸到了先确认业务影响再kill。顺序反了就是事故。

## 写在最后

把这单的经验收拢成一套流程，以后再遇到类似的卡顿可以照着走：先看等待事件，判断是不是锁；是锁，就查v$lock找BLOCK=1的会话，顺着链摸到源头；动手前先确认这笔事务能不能放弃；恢复之后，把SQL的执行计划和应用的超时设置补上。这套流程Oracle和MySQL思路一样，只是视图和命令换个名字。数据库的锁问题，很少是数据库自己的问题，多半是SQL写得糙，或者应用没管好事务。

说句实在话。锁这类问题，大多数是平时欠的账。SQL写的时候多看一眼执行计划，应用层把超时设好，也就没这些事。技术上都不难，难的是把规矩立起来，天天守着。我早年分不清死锁和阻塞，遇事就重启库，后来被线上事故教育过一次，才知道先看v$lock。这单处理完，该补的都补上了，希望各位别等出事再补。

各位遇到过哪些锁出来的诡异事故？评论区聊聊，互相避坑。

我是路远。数据库这事儿，生产环境说了算。


上周三上午十点，业务高峰，开发一个电话打过来：路哥，库死了。我登录一看就愣住了，CPU、IO、内存全都正常，业务就是卡住不动，页面转圈，订单下不了。这种比CPU打满还难搞。资源都闲着，说明不是在算，是在等。

订单系统高峰假死：40分钟长事务的enq拆参定位与并发架构复盘

业务高峰系统假死，CPU/IO/内存全正常，几十个会话却集体排队等锁。从enq等待事件拆参、v$lock阻塞链，一路摸到一笔40分钟未提交的长事务；讲透行锁如何膨胀到全表、死锁与阻塞的本质区别，并上升到并发控制粒度与Oracle/MySQL/国产库的锁模型差异。附三条避坑清单与一套可照做的排查流程。

数据库

架构设计

后端

Oracle数据库锁等待阻塞实战：业务高峰系统卡顿但CPU内存正常，实为会话集体等待enq:TX行锁与TM表锁。根因是UPDATE未走索引导致全表扫描锁膨胀，长事务40分钟未提交形成阻塞链。详解v$session、v$lock定位阻塞源头、kill会话止血方法，区分死锁与阻塞，附避坑清单。

代码解释

MySQL

OLTP

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

订单系统高峰假死：40分钟长事务的enq拆参定位与并发架构复盘-腾讯云开发者社区-腾讯云

订单系统高峰假死：40分钟长事务的enq拆参定位与并发架构复盘

订单系统高峰假死：40分钟长事务的enq拆参定位与并发架构复盘

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐