# 我把一次锁排查的踩坑交给 WorkBuddy，它给我写下了三个"视图陷阱"

> 《WorkBuddy 行业应用指南》投稿 · 完整案例
> 行业与岗位：数据库运维（DBA） / 知识沉淀与团队交接
> 工具：WorkBuddy（产出物为自建 Skill `dm-lock-forensics`）

---
![达梦DM9封面设计 (5).jpg](https://developer.qcloudimg.com/http-save/yehe-11546919/8d9914cb2a5dc69ae4a8af0b591d7acd.jpg)

## 〇、自报家门

我是干数据库运维的，圈内人叫我"数据库界华少"。

干了几年 DBA 我发现一个很现实的问题：**锁排查这件事，会的人和不 会的人，效率差十倍。** 会的人看一眼 `sys_locks` 心里有数，不会的人在十个视图里反复横跳,最后靠猜。

更扎心的是：**会的那个人一旦休假，整个团队就卡住。** 锁排查的经验，长期装在少数人的脑子里，散不掉。

这一篇要讲的，就是我如何把**一次锁排查的实战经验，交给 WorkBuddy 固化成了一个团队可复用的操作手册（Skill）**——不是让它替我查锁，而是让它**替我把经验沉淀下来**。

---

## 一、起因：那次排查,我踩了三个坑

2026-09-24，我在达梦 DM9 上排查一个"会话卡住不返回"的问题。折腾了一圈,事后复盘,我踩了三个坑，而且**三个坑都不是 SQL 语法错，是"你查错地方了"**：

**坑一：按 `TABLE_ID` 找行锁，根本找不出来。**
演示表的 `OBJECT_ID` 是 `150994945`，我顺手 `where table_id = 150994945` 去查,返回 3 行——**全是 `OBJECT` 型意向锁（IS / IX），一行行锁都没有**。后来才知道，行锁是以 `LTYPE = 'TID'` 存在的，它的 `TABLE_ID` 记的是**另一个值**（实测是 `1013`），`ROW_IDX` 和 `TID` 两列才是"哪一行"。我盯着对象 ID 翻来翻去，方向从第一步就错了。

**坑二：满屏32 行锁，真正有用的只有 1 行。**
把 `V$LOCK` 全量拉出来 32 行，逐行看才发现构成是这样的：

| 锁形态 | 模式 | BLOCKED | 行数 |
|---|---|---|---|
| OBJECT（意向锁） | IS / IX | 0 | 29 |
| TID（行锁） | X | 0 | 2 |
| **TID（行锁）** | **X** | **1** | **1** |

**29 行是事务在系统对象上登记的"我要碰这个对象"，属正常。** 只有那 1 行 `BLOCKED = 1` 立着，才是线索。新手对着这 32 行做数据分析，做到天亮也找不出根因。

**坑三：会话 `STATE = ACTIVE`，不代表它没在等锁。**
挂在锁上的那个会话，`V$SESSIONS.STATE` 依然显示 `ACTIVE`。判断"到底有没有等锁"，**要看 `V$TRXWAIT`，不能看 `STATE`**。更隐蔽的是：`SQL_TEXT` 存的是会话"当前正在执行"的语句——如果你把锁链查询跑在那个持锁的会话里，`阻塞方SQL` 那一格会显示成**你这条查询自己**。现场就"失真"了。

**这三个坑的共同点：文档上查不到，全靠踩。** 达梦的官方手册不会告诉你"按 TABLE_ID 找行锁会漏"，只会告诉你字段名。

---

## 二、输入材料：给 WorkBuddy 喂什么

这次喂的不是日志，是**我自己的踩坑记录 + 实测输出**：

| 输入材料 | 内容 | 用在哪 |
|---|---|---|
| **原始报错与困惑** | 按 `TABLE_ID` 查不到行锁的疑问、`sessid()` 函数报错 `[-2207]` | 让它复核我的判断对不对 |
| **实测输出样本** | 锁链查询的真实一行输出、`V$LOCK` 的 32 行构成 | 让它基于真实数据归纳规律 |
| **参数实测读数** | `V$DM_INI` 里 52 个锁相关参数逐条筛、`V$DYNAMIC_TABLES` 捞出的 24 个锁相关视图 | 让它自己确认"到底有没有行锁等待超时这个参数" |
| **探字典习惯** | 我常用的两条"不背名字、让库自报清单"的查询 | 作为方法论骨架 |

**为什么要喂这些？** 因为这三个坑的本质是"**知识不在文档里，在现场**"。如果我只丢一句"帮我整理下达梦锁排查方法"，它会给我一篇教科书——字段列表、语法说明,看起来很全，但**一个坑都不会提**。

**喂实测输出，它才能归纳出陷阱。**

---

## 三、WorkBuddy 配置：让沉淀有章法

我把这次沉淀当成一个**有验收标准的工程任务**来配，而不是随口聊：

| 能力层级 | 用法 | 目的 |
|---|---|---|
| **专家** | 数据库优化专家 | 定分析框架与知识组织方式 |
| **角色设定** | 资深 DBA，知识沉淀负责人 | 视角从"解一道题"转成"让别人也能解" |
| **硬性约束** | 只写实测过的、**报错就标注不确定**、给 SQL 必须能照抄 | 防止它编造版本差异 |
| **产出形态** | 结构化 Skill（四视图分工 → 陷阱 → SQL → 实测数字 → 纪律） | 团队可检索、可复用 |
| **可照抄要求** | 关联键、join 条件、函数名一律标注"实测确认，别猜" | 新人复制就能跑 |

**关键的一条约束是"报错就换一个，不要背"。** 我让它写"取会话 ID"的函数时明确要求：版本不同函数名可能不同，**报错就标注不确定**。结果它把三种写法和我实测的成功/失败都列了出来：

```
取当前会话 ID 的写法（实测）：
select sessid();                    ✅ 能跑
select sf_get_session_id();         ❌ [-2207]
select sf_get_autocommit();         ❌ [-2207]
→ 这类函数在不同版本里名字可能不一样，报错就换一个，不要背。
```

**这种"把自己踩过的错也如实标出来"的做法，是沉淀材料里最值钱的部分**——比一串永远正确的文档更可信。

---

## 四、操作步骤：四步，把经验变成 Skill

### 第 1 步｜先投喂，再让它复述

我把上面的实测输出、参数读数、三个困惑一次性喂进去，第一句话不是"帮我写文档"，而是：

```
你是资深 DBA。下面是我在达梦 DM9 上实测的锁排查过程和踩到的困惑。
请先复述：你认为我踩了哪几个坑，每个坑的判断依据是什么。
先别急着给方案，先确认我们看到的是不是同一件事。
```

**为什么要让它先复述？** 因为判断错误的根源往往不是它不懂，是**它以为我懂了**。让它先用自己的话把三个坑说出来，我一眼就能看出它有没有真的读懂。

### 第 2 步｜把"经验"强制成"可执行"

复述无误后，第二句要求变了：

```
把上面的内容整理成一个可复用的 Skill，结构固定为：
① 四视图分工表（管什么 + 关键字段）② 核心可照抄 SQL（含实测关联键）
③ 视图陷阱（每条写清"错在哪 + 正确姿势"）④ 实测数字表
⑤ 安全造锁手法 ⑥ 探字典习惯 ⑦ 读数纪律。
凡是你没有实测过的，一律标注"未核实"，不许推测。
```

**"不许推测"这条约束是灵魂。** DBA 最怕的不是踩坑，是**被一篇写得漂亮但字段名是编的文档坑**。

### 第 3 步｜造锁验证：安全地做一次并发实验

光有输出还不够，怎么证明这套方法在新会话里真能跑？让它给一个**不改数据的造锁实验**方案。它给的思路很关键：

**首选 `select ... for update`，不要用 `update`。**
理由很实在：只加行锁、不改任何一行、一直不提交也不产生脏数据，`rollback` 一把就净。而 `update` 改了还得改回来，副作用带出去了。

并附了三条铁律，其中一条是新手必踩的：

> **必须两个独立连接。** 同一会话自己拿自己的锁，**永远不会阻塞**。
> 实测反例：三条语句贴进同一窗口，`for update` **0.687 毫秒**就返回，执行号 69216–69220 **连号** → 锁在，但没人等。
> **图形客户端的多个"查询页"常共用一条连接**——看着两个页签，其实是同一个会话。

它还提醒：**验证两个窗口真是两个会话**，两边各跑一次 `select sessid();`，数字不一样才算。

**为什么这条值得写进去？** 因为"造锁造了半天发现没造出来"，是每个 DBA 都干过的蠢事——而且**当时你是不会怀疑的**，因为语句确实返回了。

### 第 4 步｜立一条"读数纪律"

最后我要求补一节读数纪律，它自己加了一条我原文没写的：

> **引用旧笔记里的统计数字前，必须逐行重数一遍。**
> 实测教训：笔记里写"32 行中 30 行属同一事务"，逐行核对实为 **27 行（7285）+ 5 行（7289）**。类别计数是高风险数字，默认会错。

**这一条让我服气。** 我笔记里那个"30 行"是当初顺手写的，它不仅没顺着抄，还把错纠正了。这就是我前面反复说的那句：**AI 交活，我签字。但它确实能替我复核。**

---

## 五、产出物：一个团队可复用的 Skill

产出物是一个结构化 Skill `dm-lock-forensics`，**5 大块，全部实测可直接引用**：

### 1. 四视图分工表（少一个都拼不出完整现场）

| 视图 | 管什么 | 关键字段 |
|---|---|---|
| `V$LOCKED_OBJECT` | 会话 → 被锁**对象**（对象粒度） | `SESSION_ID` / `OBJECT_ID` / `LOCKED_MODE` |
| `V$LOCK` | **锁本身** | `ADDR` / `TRX_ID` / `LTYPE` / `BLOCKED` / `ROW_IDX` |
| `V$TRXWAIT` | **等待关系**（谁等谁、等多久） | `ID` / `WAIT_FOR_ID` / `WAIT_TIME` / `WAIT_FOR_LOCK` |
| `V$SESSIONS` | **人头**（事务 → 会话 → SQL → IP） | `SESS_ID` / `TRX_ID` / `STATE` / `SQL_TEXT` |
| `V$DEADLOCK_HISTORY` | 死锁案卷 | `TRX_ID` / `HAPPEN_TIME` / **`DEADLOCK_CYCLE`** |

### 2. 核心交付物：锁链查询（关联键已实测，照抄能跑）

```sql
select w.ID                   as 等待事务,
       ws.SESS_ID             as 等待会话,
       ws.CLNT_IP             as 等待来源,
       ws.SQL_TEXT            as 等待的SQL,
       w.WAIT_FOR_ID          as 阻塞事务,
       bs.SQL_TEXT            as 阻塞方SQL,
       w.WAIT_TIME            as 已等待,
       l.LTYPE                as 被等锁类型,
       l.LMODE                as 被等锁模式,
       l.BLOCKED              as 阻塞标记
  from v$trxwait w
  left join v$sessions ws on ws.TRX_ID = w.ID
  left join v$sessions bs on bs.TRX_ID = w.WAIT_FOR_ID
  left join v$lock     l  on l.ADDR    = w.WAIT_FOR_LOCK;
```

> ★ **关联键（实测确认，别猜）**：`v$trxwait.LOCK` / `WAIT_FOR_LOCK` = `v$lock.ADDR`；`v$trxwait.ID` / `WAIT_FOR_ID` = `v$sessions.TRX_ID`。

实测输出示例（一行）：

```
等待事务 7289 / 阻塞事务 7285 / 已等待 448347
被等锁类型 TID / 被等锁模式 X / 阻塞标记 0
```

### 3. 实测数字表（可直接写进报告，每条都有出处）

| 事实 | 实测值 |
|---|---|
| **锁等待默认无超时** | 挂满 **9 分 34 秒**（已用时间 `00:09:34.766` = 574.766 秒），零报错、零告警 |
| **`WAIT_TIME` 单位** | **毫秒**。两点采样 476079 → 503265，差 27186，对应墙上约 27 秒 |
| **死锁检测耗时** | `[-6403]:死锁.` 已用时间 **566.928 毫秒** |
| **死锁检测参数** | `DEADLOCK_CHECK_INTERVAL = 1000`（毫秒）→ **周期扫描，不是即时判决** |
| **52 个锁相关参数里** | **没有"行锁等待超时"这一项** |
| 死锁环读法 | `DEADLOCK_CYCLE` = `self -> (7291, 会话ID) -> self`，**一行字符串就是死锁环的全部结构** |

### 4. 探字典习惯（排查第一步，先让库自报清单）

```sql
-- 不背视图名，让库自报清单
select name from v$dynamic_tables
 where name like '%LOCK%' or name like '%TRX%'
    or name like '%WAIT%' or name like '%DEADLOCK%'
 order by name;                                    -- 实测 24 行

-- 不背参数名
select para_name, para_value, para_type from v$dm_ini
 where para_name like '%LOCK%' or para_name like '%TRX%'
    or para_name like '%WAIT%' order by para_name;  -- 实测 52 行
```

### 5. 安全造锁手法（不改数据、可回滚、跨环境通用）

`select … for update` 优于 `update`；靶子用新建 3 行小表，不要在千万行大表上做；两个独立连接 + `select sessid();` 验证；`set autocommit off;` 关自动提交。

---

## 六、成果：经验从"个人"变成"团队"

这件事的价值，不在于我又学会了一个技巧，而在于：

| 沉淀前 | 沉淀后 |
|---|---|
| 三个陷阱只在我脑子里 | 任何人接手排锁，**先看陷阱表**，少走三条弯路 |
| 锁链 SQL 每次现写，现写现错 | **关联键已实测，照抄能跑** |
| 参数是"听说"，不确定 | 实测数字表，**每条带出处和单位** |
| 新人靠人带 | Skill 可检索、可复用，**可交接** |

**我个人的原则是：可以让 AI 干体力活，但知识资产必须带出处。** 所以这份 Skill 里，每一条结论都标注了是"实测"还是"未核实"，每一条参数都写了单位和口径。这不是洁癖——**知识资产一旦混入编造的内容，信任就没了，比没有文档更糟。**

顺带一个对照：这套"采集与诊断分离、现场先于结论、数字必须标口径"的打法，和我处理数据库事故的底层习惯是一致的——**先还原现场，再下判断；先给数字，再给结论。**

---

## 七、这套方法能复用到哪

**沉淀方法论，比沉淀某条命令更值钱。** 这套"投喂实测 → 让它复述 → 强制可执行 → 造实验验证 → 立读数纪律"的五步法，我后来复用到：

- **达梦并行查询（PARALLEL_POLICY）实测核实**——同样用"不背参数名、让库自报清单"起手，逐条核实"参数改了为什么没生效"；
- **国产数据库锁与死锁排查**——把新库当新战场，先跑一遍"探字典 + 造锁 + 读数字"，10 分钟就知道它的脾气；
- **团队的交接文档**——把"我只说过一遍但没人记住"的东西，变成能检索、能照做的操作手册。

**一句话总结：AI 让我一个人的经验，变成整个团队的工具。**

《WorkBuddy 行业应用指南》投稿 · 完整案例 行业与岗位：数据库运维（DBA） / 知识沉淀与团队交接 工具：WorkBuddy（产出物为自建 Skill dm-lock-forensics）

【征文】我把一次锁排查的踩坑交给 WorkBuddy

运维工程师

数据库

运维

编程语言

数据库运维专家将锁排查实战经验沉淀为WorkBuddy可复用Skill，总结三大视图陷阱：按TABLE_ID查行锁会漏、满屏锁行仅一条关键、STATE字段无法判断锁等待。产出物含四视图分工表、实测锁链SQL、数字表、造锁手法，全部经实测验证，让团队新人直接照抄避坑。

数据库优化

数据库运维

数据分析

代码解释

WorkBuddy 

2026上云采购 | AI焕新·智启新局

workbuddy

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

【征文】我把一次锁排查的踩坑交给 WorkBuddy-腾讯云开发者社区-腾讯云

【征文】我把一次锁排查的踩坑交给 WorkBuddy

【征文】我把一次锁排查的踩坑交给 WorkBuddy

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐