# 锁等待没有超时！达梦金仓实测，我做了个 Skill

九月下旬的一个下午，我在一台达梦上做锁实验。

屏幕上挂着一条 `select ... for update`，我盯着它的「已用时间」一路往上爬。爬到 `00:09:34.766` 的时候我停了手。

九分三十四秒。这条语句一直在等一把锁，零报错，零告警，安安静静。

我没去感叹这锁有多顽固。脑子里冒出来的是另一个问题。

**它凭什么能等这么久？**

这个问题后来成了我这份 Skill 的起点。它把我过去三年遇到的两件事串到了一起，一件在达梦，一件在金仓。

![cover-b.png](https://developer.qcloudimg.com/http-save/yehe-11546919/1f9ad6adec6d7c479acd9b551496ae28.png)

## 一、九分三十四秒，和一条不该存在的超时

先说达梦那边。

我做的实验很简单，两个独立连接，窗口① 执行完 `for update` 就不提交，窗口② 去更新同一行。按常识，数据库总该有个「等太久就放弃」的机制吧。

实测结果是，没有。

![1.png](https://developer.qcloudimg.com/http-save/yehe-11546919/614733613623121709d383abe487d76b.png)

![2.png](https://developer.qcloudimg.com/http-save/yehe-11546919/c09be9dd80136ab0cfd43caf2d3e7c35.png)

那条语句就那么挂着，一路挂到 574.766 秒。中间我翻了 52 个带 `LOCK` / `TRX` / `WAIT` 字样的参数，想找出「行锁等待超时」是哪一项。

不存在这么一项。

带 `TIMEOUT` 的参数只有 5 个，`DPC_TRX_TIMEOUT`、`DSC_SLOT_WAIT_TIMEOUT`、`MAL_WAIT_TIMEOUT`、`REDOS_WAIT_TIMEOUT`、`TSMV_WAIT_TIMEOUT`，名字看着都对，各管一段，唯独不管行锁等待。

顺手还量了死锁检测的耗时，`[-6403]: 死锁.` 的「已用时间」是 566.928 毫秒。对应的参数 `DEADLOCK_CHECK_INTERVAL = 1000`，单位毫秒。

也就是说，死锁是**周期扫描**判出来的，不是当场发现。这个数字后面很有用，先按下不表。


![image.png](https://developer.qcloudimg.com/http-save/yehe-11546919/5a32c9cbf094f58752e83c0e075d896b.png)

那一刻我意识到一件挺要命的事。

**谁堵了谁，这一步其实不难查，工具和视图都现成的。难的是没人再往下问一句，为什么可以堵这么久。**

后面这半句，才是扎在肉里的那根刺。

---

## 二、同一副病灶，在金仓上收了 12 分钟的账

如果只是实验室里挂着九分钟，那还好说。问题是它在生产上真的会发生。

差不多同一时期，另一个项目里，一套生产上的金仓（KingbaseES，PostgreSQL 兼容模式）上，秒杀库存表 `flash_sale_sku` 卡住了。

采集包拉出来，现场是这样三个会话。

| 角色 | 会话 | 在跑什么 | 状态 |
|---|---|---|---|
| 根因阻塞者 A | 3699177 | `UPDATE flash_sale_sku SET available_stock = available_stock - 1` | idle in transaction，挂起 802 秒 |
| 根因阻塞者 B | 3737844 | `SELECT ... FROM information_schema.tables WHERE table_name LIKE '%log%'` | idle in transaction，挂起 769 秒 |
| 受害者 | 3738034 | 和 A 同一条减库存 UPDATE | active，`wait_event = transactionid`，已等 783 秒 |

```
┌──────────────────────────────────────────┐
│ pid=3699177  根因阻塞者 A                 │
│ UPDATE flash_sale_sku ...                 │
│ idle in transaction · 已挂起 802s          │
│ 持有 transactionid 排他锁（未提交）         │
└──────────────────────────────────────────┘
              │ 阻塞
              ▼
┌──────────────────────────────────────────┐
│ pid=3737844  根因阻塞者 B                 │
│ SELECT ... FROM information_schema.tables │
│ idle in transaction · 已挂起 769s          │
│ 同样持有 transactionid 排他锁（未提交）      │
└──────────────────────────────────────────┘
              │ 阻塞
              ▼
┌──────────────────────────────────────────┐
│ pid=3738034  受害者                       │
│ UPDATE flash_sale_sku ...                 │
│ active · wait_event = transactionid       │
│ 已等 783s                                 │
└──────────────────────────────────────────┘
```
![锁侦探生成的诊断报告.png](https://developer.qcloudimg.com/http-save/yehe-11546919/bf09422bd4d7fe02d3ee3b3ad537e402.png)

注意这是个「双根因、单受害者」的结构。受害者被 A 和 B 同时堵着，只要那两个里任意一个不松手，它就永远别想拿到锁。

这个结构，单看一条阻塞链是看不出来的。

更扎心的是那两个根因的成色。A 是一笔没提交的减库存，还算「业务没写对」。B 呢？B 只是一句查 `information_schema` 的元数据查询，人畜无害的一句话，它怎么会在长事务里？

答案不在这一句上。它说明 B 前面在同一个事务里做过写操作，然后忘了提交。一栋楼塌了，根子在地基不在外墙。

然后我去核对参数，画面就完整了。

| 参数 | 当时的值 | 后果 |
|---|---|---|
| `idle_in_transaction_session_timeout` | 0 | 空闲事务可以永久挂着，永不自动清理 |
| `lock_timeout` | 0 | 锁等待没有上限，受害者永远卡死 |
| `statement_timeout` | 0 | 单条语句没有兜底 |
| `deadlock_timeout` | 1000ms | 偏激进，高并发下容易误判 |

三项全 0。

这就是达梦那九分三十四秒的另一个版本，只是这次代价更实在。阻塞一路累积到 769 秒，十二分钟多，中间没有任何机制出来喊停。

写到这里我想插一句。**上来就加索引是治错了地方。** 那张表上主键索引 `flash_sale_sku_pkey` 一直都在，索引层面没有毛病。瓶颈在事务管理，不在缺索引。这一点当时差点被判错。

---

## 三、两个数据库，同一副病

把上面两件事并排放在一起看，会浮出来一个东西。

| | 达梦 DM9 | 金仓 KingbaseES |
|---|---|---|
| 我遇到的现象 | 锁等待 9 分 34 秒，零报错 | 锁等待 769 秒，累积成雪崩 |
| 有没有超时拦截 | 52 个锁参数里找不到 | 三个关键参数全为 0 |
| 本质 | **同一个病** | 同一个病 |

两个完全不同的数据库厂商，两套完全不同的系统视图，背后站着的是同一副病灶。

数据库默认不会替你踩刹车。锁等待和空闲事务这两件事，超时防护不开，它就真的能一直等下去，等到天荒地老。

这就是我决定动手写 Skill 的原因。有两个。

一层是单个人的经验撑不住两个库。金仓出问题，你记得去翻 `pg_locks`；达梦出问题，你记得去翻 `V$TRXWAIT`。两个库，两套肌肉记忆，还得记住各自的坑。

另一层是这个空还没人补。腾讯云云数据库侧的智能巡检能力，覆盖的是 MySQL、PostgreSQL、MongoDB、Redis 这几类引擎，锁与事务排查是里面现成的一项。用腾讯云托管实例的团队基本够用。但自建的达梦和金仓不在这个名单里。这两家的锁视图跟 PG 是两套东西，云上 SaaS 巡检够不着，社区里也翻不到一份把两家讲清楚的对照。

可是这套东西的骨架明明只有一个。

**等待关系、锁本身、会话人头、被锁对象，四类证据凑齐，任何一个库的阻塞链都能还原。**

差别只在视图名。

那么问题就变成，能不能把「骨架」和「方言」拆开，骨架留给人，方言交给一份可复用的资产？

---

## 四、于是有了这个 Skill

我把它叫做 `cloudq-lock-forensics`。它是从我自己在用的那份达梦锁取证笔记里长出来的。

先说它长什么样。CloudQ 的 Skill 用的是业界通用目录约定，一个 Skill 就是一个目录。

```
cloudq-lock-forensics/
├── SKILL.md                      # 元数据 + 指令正文
├── references/
│   ├── dm-lock-traps.md          # 达梦四视图分工 + 三个陷阱 + 实测数字
│   └── kingbase-pg-lock.md       # 金仓案例复盘 + 参数口径
└── scripts/
    ├── dm_lock_chain.sql         # 达梦锁链查询（关联键实测确认）
    └── kingbase_lock_chain.sql   # 金仓锁链查询
```

元数据只有两个字段，`name` 和 `description`，`description` 负责说清「做什么 + 什么时候用我」。工具、步骤、边界、铁律全部写进正文。

正文的骨架是四段，工具与证据边界、执行步骤、安全边界、铁律。

### 执行步骤，六步

我把过去的排查动作拆成了六步。前四步是常规操作，第五步是我认为最容易被漏掉的一步。

1. **定方言，探字典。** 不背视图名，让库自己报清单。
2. **抓等待关系。** 这一步只回答一个问题，有没有人在等锁。
3. **补人头。** 沿事务号把两端补齐成「谁、从哪来、在跑什么」。
4. **还原阻塞链，区分三种角色。** 根因阻塞者、中间传导者、受害者。
5. **核对超时防护缺口。** 就是前面那个「凭什么能等这么久」。
6. **输出证据链与分级处置。** 结论、阻塞链、分级处置三块，附可直接执行的语句。

第六步的处置建议，只会产出「建议」，不会替你去 `kill` 会话。这个后面讲。

### 那些踩过的坑，直接写成了铁律

这份 Skill 最值钱的地方，是那些踩烂的坑。我把它们一字一句钉了进去。挑三条说。

**第一条，判断有没有在等锁，只看等待关系视图，不看会话状态。**

达梦实测，一个挂在锁上的会话，它的 `V$SESSIONS.STATE` 依然显示 `ACTIVE`。你如果只看状态，会以为它活得好好的。这就是那条九分三十四秒的语句，状态栏一直骗你九分钟。

**第二条，锁链查询必须放在第三个会话里跑。**

会话视图里的 SQL 文本存的是「这个会话此刻正在执行的语句」。你要是把锁链查询放进持锁那个会话里执行，输出里阻塞方那一栏会显示成这条查询它自己。

我用亲身经历验证过这一点，第一次跑出来的结果里，根因那一格写着我自己，当时我还愣了几秒。

**第三条，行锁不能靠表的对象 ID 去找。**

我那张演示表 `t_lock_demo` 的对象 ID 是 `150994945`。我拿着这个 ID 去 `V$LOCK` 里筛，回来 3 行，全是 `OBJECT` 型的意向锁，一行行锁都没有。

行锁藏在 `LTYPE = 'TID'` 里面，它的 `TABLE_ID` 记的是另一个值，实测 `1013`。你拿表的对象 ID 去找行锁，永远找不到。

这三条坑还有一个共同点，它们都不会报错。数据库不会提醒你「你查错地方了」，它就安安静静给你一个错答案。

顺带说一条作风纪律，也写进了铁律。**类别计数必须逐行重数。** 我旧笔记里写过「32 行中 30 行属同一事务」，后来逐行核对，实际是 27 行加 5 行。统计数字这个东西，默认会错，引用前重数一遍。

---

## 五、挂上去跑了一次，撞了三个坑

写完之后我没急着交稿。找了个真实环境，把它挂上去跑了一遍。

CloudQ 在 WorkBuddy 里是原生支持的，左列「专家·技能·连接器」搜一下就在，七千多次使用，不是个没人碰的新东西。

​![WorkBuddy 的专家页，多云AIOps专家排在第一个.png](https://developer.qcloudimg.com/http-save/yehe-11546919/f0e468d3a6d0dcb29410bf791a356f9e.png)

一台金仓，KingbaseES V009R003C018，PG 12 内核，库名 `mcp_demo`。通道走 WorkBuddy 里的 `kingbase-mcp`，只读 SQL。

![实跑现场。左边是 CloudQ 给的结论，右边是它当场生成、并且逐节在库上跑过的诊断脚本.png](https://developer.qcloudimg.com/http-save/yehe-11546919/1a7d3ebe6d06d661a1d936973e4a7830.png)

第一轮结果有点意外。它确实连上了，也跑通了，同时撞出三个坑。三个都不大，三个都很要命。

### 坑一，内置工具是坏的

最难看的先放前面。这套 MCP 自带的 `list_schemas`，一调就报错。

```
字段 "schema_owner" 不存在
```

不是连接问题。是它拿 PostgreSQL 原生的字典视图在查金仓，金仓的字典视图改过，这个字段没了。

一个「通用」的库工具，在国产库上第一刀就折了。

绕开的办法是不碰它，所有诊断都走 `execute_sql`。

### 坑二，那个字段在 PG 14 才有

我想精确算「这个会话到底等了多久」，最直觉的写法是 `now() - waitstart`。

这台实例没有这个字段。

`waitstart` 是 PG 14 才加进 `pg_locks` 的，这台的内核是 PG 12。所以等锁时长只能退一步，用 `now() - query_start` 推算。

它不是精确值。语句开始执行的时间，和开始等锁的时间，中间隔着一小段。差多少，取决于这条 SQL 在等锁之前跑了多久。

### 坑三，那个 `0::bigint`

这条跟数据库没关系，是我自己写出来的。

追多层级阻塞树要用递归 CTE。锚点那层我写了 `0`，数据库报类型不一致。

原因是递归那部分算出来是 bigint，锚点给的是 integer，两边对不上。显式写成 `0::bigint` 就过去了。

这种坑最磨人。它跟业务逻辑一点关系没有，纯粹是代码层的脾气。

### 然后是我没预料到的那件事

我以为金仓就是 PG 套个壳。跑下来发现不是。

金仓有一个 PG 系没有的视图，叫 `sys_stat_instlock`。它记的是**历史锁等待统计**。每个锁对象累计加锁多少次，进过几次等待队列，超时过几次，真正堵过几次。

这个价值在哪。

现场没了也能查。

回头看前面那两件事。达梦那九分三十四秒，金仓那十二分钟。等 DBA 赶到，锁早解开了，`pg_locks` 干干净净。你手上什么都没有，只能听业务方说一句「刚才卡了」。

`sys_stat_instlock` 把这个局面翻了。`wait_times` 大于 0 就说明历史上堵过，而且能告诉你是堵在哪个锁对象上。

这不是 PG 的能力。是金仓自己加的。

### 所以，Skill 到底值钱在哪

这一轮跑完，我对「Skill 资产」这四个字的理解变了。

原来我以为，它的价值是「把排查步骤写下来，让 AI 照着做」。

跑完发现不是。

通用的 AI 什么都会写。`pg_locks`、`pg_stat_activity`、递归 CTE，它写得比我还快。但它不知道这台库是 PG 12 内核，不知道 `waitstart` 在这里不存在，不知道 `schema_owner` 会直接报错，更不知道金仓偷偷塞了个 `sys_stat_instlock` 进去。

这些它都不知道。

**流程是可以现推的。值钱的是脾气。**

那三条坑，我一条没落，全写进了铁律。

---

## 六、把它对齐信通院的标准

征文里提到，Skill 资产可以逐一对标信通院《云上 Agent 基准度量模型》。这份模型把 Agent 能力分成六个维度，按三层管理。我对着这张表把自己的 Skill 过了一遍。

| 维度 | 层级 | 在这个 Skill 里怎么落 |
|---|---|---|
| **功能性** | 红线 | 五类证据齐备才下结论。阻塞链必须区分根因、传导、受害者，不做平铺罗列 |
| **安全性** | 红线 | 全程只读。终止会话、修改参数一律只出建议，回用户侧授权 |
| **可靠性** | 核心 | 降级不中断，某一维度采集失败其余照常输出。视图缺失、字段不存在，一律标注「未知」，不推断、不补证据 |
| **成本效益** | 核心 | 一次采集产出一份完整证据链，替代逐条手工查视图。同一批数据可以反复用于复盘 |
| **用户体验** | 评价 | 输出三段式，结论在前。每条处置附可直接执行的语句，并按风险分三级 |
| **性能效率** | 评价 | 只读查询走系统视图，不扫业务表。锁链查询固定在不持锁的第三个会话执行，避免污染证据 |

对标的过程中，有两个地方我是诚实的。

一是「安全性」这条红线。一个能 `kill` 会话的 Skill 看着很酷，但它不该有那个权限。诊断归诊断，处置归处置，中间隔一道人工确认。这条线我划得很死。

二是「成本效益」这一项，我不打算给它编一个漂亮的提升百分比。真实的账是这样的，从采集到出报告，大约两分半。这笔账我认。

---

## 七、这个 Skill 不做什么

写到这儿，得说说它的边界。一个不讲边界的 Skill，比没有更危险。

**它不做变更。** `kill`、`pg_terminate_backend`、`ALTER SYSTEM` 这些动作，它只写建议，不执行。生产上终止一个会话会回滚该会话未提交的事务，这个动作必须有人签字。

**它不推断证据。** 死锁日志没开，它就写「死锁历史不可用」，不会猜一个出来。视图里没有的字段，它标「未知」。

**它有够不着的地方。** 应用侧的连接池状态、进程级内存快照，都不在它的采集范围。需要这些才能定论的场景，它只输出假设，并明确标注「待验证」。

最后一条边界最近刚被现实撞了一次。我在排查某套 OceanBase 的 OOM，`memory_limit_percentage` 默认 90%，但实例在 100% 卡死了，怀疑是 OS 层进程占用超了限。这个链条需要的是内存快照和 OS 侧进程信息。

我的 Skill 够不着这一段，它老老实实说够不着。这反而是对的。

---

## 八、写在最后

从「九分三十四秒」到一份能被调用的资产，技术上的活儿其实不多。

卡住人的是那个念头，把只活在自己脑子里的判断逻辑，从一个人的直觉变成一份能交给别人跑的东西。

我认识的老 DBA 里，好多人手上都揣着一套自己都没意识到的资产。半夜告警炸了，他十分钟摸到根因，问他怎么摸到的，他说「感觉」。这个「感觉」拆开看，是几十次踩坑攒出来的条件反射。

这些东西眼下还都在人脑里。人走了，它跟着走。

我干的这事不算大，就是把其中一块拆出来，钉成了一份能跑的文本。

手里有类似块头的，我建议你也拆一个。不用多完整，把踩烂的那三条坑写清楚，它就有人用得上了。

*（本文相关 Skill 资产：`cloudq-lock-forensics`，含 1 份 SKILL.md、2 份 references、2 份 SQL 脚本、1 份只读采集器。金仓案例数据来自 2026-08-08 采集包，达梦数据来自 2026-09-24 实测，Skill 上机验证于 2026-10-17 在 KingbaseES V009R003C018 完成。）*


屏幕上挂着一条 select ... for update，我盯着它的「已用时间」一路往上爬。爬到 00:09:34.766 的时候我停了手。

锁等待没有超时！达梦金仓实测，我做了个 Skill

达梦锁等待 9 分 34 秒，金仓阻塞 769 秒，两个数据库同一副病：没人拦。我把这套排查逻辑做成 cloudq-lock-forensics，挂到 CloudQ 上真跑了一次，撞出三个版本坑，也撞见了金仓独有的 sys_stat_instlock。

运维工程师

数据库

运维

开发工具

锁等待排查发现达梦与金仓数据库超时防护机制默认全关，导致锁等待最长超9分钟、12分钟无拦截。实战验证的数据库锁诊断Skill资产，覆盖双库锁链查询、铁律避坑、只读安全边界，输出完整证据链与分级处置建议。

代码解释

云数据库

PostgreSQL

WorkBuddy 

云托管

MongoDB

CloudQ

MySQL

Agent

Redis

SaaS

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

锁等待没有超时！达梦金仓实测，我做了个 Skill-腾讯云开发者社区-腾讯云

锁等待没有超时！达梦金仓实测，我做了个 Skill

锁等待没有超时！达梦金仓实测，我做了个 Skill

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐