达梦数据库死锁实战：5分钟快速定位问题会话（附常用SQL查询模板）
达梦数据库死锁实战：5分钟快速定位问题会话（附常用SQL查询模板）
凌晨三点，监控告警的铃声划破了寂静。屏幕上，核心业务系统的响应时间曲线陡然飙升，应用日志里开始零星出现“锁等待超时”的报错。作为DBA，你很清楚，这大概率不是简单的慢查询，而可能是更棘手的“死锁”在作祟。生产环境的死锁就像一场突如其来的交通瘫痪，它不给你太多分析根源的时间，首要任务是快速疏通，恢复业务。本文不探讨长篇大论的理论，而是聚焦于这个“救火”场景，分享一套经过实战检验的、能在5分钟内锁定问题会话并实施干预的“作战手册”。无论你是经验丰富的DBA，还是首次直面生产死锁的运维工程师，这里的SQL模板和操作思路，都能帮你稳住阵脚。
1. 死锁的“第一现场”：如何快速捕获关键信息
当告警响起，你的第一反应不应该是打开文档从头学习，而是直奔“案发现场”收集证据。在达梦数据库中，有几个动态性能视图（V$视图）是勘查死锁现场的关键目击者。我们的目标是，用最少的查询，拿到最全的信息：谁（哪个会话）卡住了谁，在做什么（SQL），从哪里来（客户端信息）。
首先，我们需要一个能一览全局的查询。这个查询的核心思路是关联V$LOCK（锁信息）、V$TRXWAIT（事务等待信息）、V$TRX（事务信息）和V$SESSIONS（会话信息）。
SELECT vs.SESS_ID AS `阻塞会话ID`, vs.SQL_TEXT AS `当前执行SQL`, vs.APPNAME AS `应用名称`, vs.CLNT_IP AS `客户端IP`, lc.BLOCKED AS `是否被阻塞`, lc.TABLE_ID AS `被锁表ID`, (SELECT TABLE_NAME FROM DBA_TABLES WHERE TID = lc.TABLE_ID) AS `表名`, vtw.ID AS `等待的事务ID` FROM V$LOCK lc LEFT JOIN V$TRXWAIT vtw ON lc.TRX_ID = vtw.ID LEFT JOIN V$TRX vt ON vtw.ID = vt.ID LEFT JOIN V$SESSIONS vs ON vt.SESS_ID = vs.SESS_ID WHERE vs.SQL_TEXT IS NOT NULL ORDER BY lc.BLOCKED DESC;执行这个查询，你可能会看到类似下面的结果（示例）：
| 阻塞会话ID | 当前执行SQL | 应用名称 | 客户端IP | 是否被阻塞 | 表名 |
|---|---|---|---|---|---|
| 1397145640 | UPDATE orders SET status='PAID' WHERE order_id=1001 | OrderService | 192.168.1.101 | 0 | ORDERS |
| 1502287901 | UPDATE inventory SET stock=stock-1 WHERE product_id=2002 | InventoryApp | 192.168.1.102 | 1 | INVENTORY |
注意：
BLOCKED列为1表示该会话正在等待锁资源（即被阻塞），为0表示它持有锁并可能阻塞了别人。上表中，ID为1502287901的会话正在等待，而1397145640的会话持有锁。这很可能构成了一个死锁环的一部分。
仅仅知道谁被阻塞还不够，我们需要找到阻塞源头。另一个更直接的查询可以快速定位正在等待锁的会话及其在等待谁：
SELECT w.sess_id AS `等待会话ID`, w.sql_text AS `等待会话SQL`, h.sess_id AS `持有锁会话ID`, h.sql_text AS `持有锁会话SQL` FROM v$lock l1 JOIN v$sessions w ON l1.sess_id = w.sess_id AND l1.blocked = 1 JOIN v$lock l2 ON l1.table_id = l2.table_id AND l2.blocked = 0 AND l1.lmode <> l2.lmode JOIN v$sessions h ON l2.sess_id = h.sess_id;这个查询通过锁表（TABLE_ID）关联，直接找出“等待者”和“持有者”的配对，对于快速理解锁争用关系非常直观。
2. 深度诊断：剖析死锁链条与事务详情
拿到初步的会话ID后，我们需要深入一层，查看这些会话背后的事务在做什么。这有助于判断强制终止哪个会话的代价更小，或者为后续优化提供线索。
首先，查询特定会话的详细事务信息。将下面SQL中的你的会话ID替换为实际值。
SELECT vt.ID AS `事务ID`, vt.STATUS AS `事务状态`, vt.START_TIME AS `事务开始时间`, vs.SESS_ID, vs.SQL_TEXT, vs.APPNAME, vs.CLNT_HOSTNAME AS `客户端主机名` FROM V$TRX vt JOIN V$SESSIONS vs ON vt.SESS_ID = vs.SESS_ID WHERE vs.SESS_ID = 你的会话ID;事务状态（STATUS）很关键，ACTIVE表示正在进行，ROLLBACK表示正在回滚。如果一个事务已经活跃了很长时间并持有锁，它成为“牺牲品”的优先级可能更高。
其次，查看锁的详细模式和类型。达梦数据库中，锁模式（LMODE）是一个数字，其含义如下表所示：
| LMODE值 | 锁模式 | 描述 |
|---|---|---|
| 0 | NULL | 无锁 |
| 1 | SS（行共享锁） | 允许其他事务读同一行，但禁止排他锁 |
| 2 | SX（行排他锁） | 禁止其他事务获取任何锁（共享或排他） |
| 3 | S（表共享锁） | 允许其他事务读整个表，但禁止更新 |
| 4 | X（表排他锁） | 禁止其他事务以任何方式访问该表 |
| 5 | SRX（共享行排他锁） | 比SX限制稍弱，允许其他事务加SS锁 |
了解锁模式有助于判断死锁的严重性。例如，两个会话互相等待对方的X（排他）锁，这就是典型的、必须立即打破的死锁。
我们可以通过以下查询，查看当前系统中所有非NULL的锁：
SELECT s.SESS_ID, s.SQL_TEXT, l.TABLE_ID, (SELECT TABLE_NAME FROM DBA_TABLES WHERE TID = l.TABLE_ID) AS TABLE_NAME, l.LMODE, l.BLOCKED FROM V$LOCK l JOIN V$SESSIONS s ON l.SESS_ID = s.SESS_ID WHERE l.LMODE > 0 ORDER BY l.BLOCKED DESC, l.TABLE_ID;3. 紧急干预：安全终止问题会话的决策与操作
诊断完成后，就来到了决策时刻：终止哪个会话？理想情况下，我们应该终止那个对业务影响最小、回滚代价最低、或是引发问题的根源会话。这需要结合业务知识来判断。例如：
- 终止来自报表查询系统的会话，通常比终止来自核心交易系统的会话影响小。
- 终止刚刚开始、修改数据量少的事务，比终止一个运行了半小时、修改了上万行数据的事务更安全。
- 如果其中一个会话的SQL明显存在逻辑问题（如缺失索引导致全表锁），那么它可能是更好的终止对象。
一旦做出决定，就使用达梦数据库提供的“手术刀”——SP_CLOSE_SESSION系统存储过程。它的用法极其简单，但威力巨大：
CALL SP_CLOSE_SESSION(要终止的会话ID);例如，要终止我们之前例子中 SESS_ID 为1397145640的会话：
CALL SP_CLOSE_SESSION(1397145640);执行后，数据库会立即向该会话发送中断信号，其当前事务会被回滚，连接断开。
重要警告：
SP_CLOSE_SESSION是强制手段。被终止会话正在进行的所有工作都会丢失并回滚。务必确保：
- 你终止的是正确的会话ID，双击确认。
- 已经评估了该会话终止对关联业务功能的影响。
- 最好（如果条件允许）通知相关应用负责人。
操作完成后，立即回到第一步的查询，确认死锁链是否已被打破，系统锁等待是否消失。同时，观察应用监控，看业务响应是否恢复正常。
4. 事后复盘与防御性优化
“火”被扑灭后，工作只完成了一半。真正的价值在于复盘，防止同类型的“火灾”再次发生。你不能只满足于当个“救火队员”。
首先，收集死锁发生时的完整证据。达梦数据库的死锁信息通常会在跟踪文件或系统日志中留有更详细的记录。你可以检查dm.ini配置文件中SVR_LOG相关的参数是否开启，或者直接查询最近的相关日志。一个更系统的方法是，考虑在死锁发生时自动捕获信息。虽然达梦不像某些数据库有直接的死锁图事件，但你可以通过定期查询V$TRXWAIT和V$LOCK并记录长时间等待的方式，自己搭建一个简单的监控脚本。
其次，分析死锁的根本原因。大部分应用层的死锁可以归为以下几类，你可以拿着之前捕获的SQL语句对照检查：
- 锁顺序不一致：两个事务以不同的顺序访问和锁定多张表。这是最常见的死锁原因。
- 事务A:
锁表X -> 锁表Y - 事务B:
锁表Y -> 锁表X
- 事务A:
- 缺失索引导致锁升级：一条UPDATE或DELETE语句因为WHERE条件列没有索引，导致数据库无法精确定位行，只能锁住更大范围（页锁）甚至整个表（表锁），大大增加了冲突概率。
- 长事务：一个事务长时间不提交，持有着锁，成为其他事务的“拦路虎”。
- 事务隔离级别的影响：在更高的隔离级别（如达梦的
READ COMMITTED以上）下，锁的范围和持有时间可能会发生变化。
针对性的优化策略：
- 统一访问顺序：在应用代码规范中，强制规定对核心业务表的访问必须遵循相同的顺序（例如，总是先
订单表再库存表）。 - 为查询条件添加索引：确保高频更新的SQL语句其WHERE条件、JOIN条件上的字段有合适的索引，避免锁升级。使用
EXPLAIN分析执行计划是关键。 - 缩小事务范围：让事务尽可能短小精悍，做完了立即提交。避免在事务内进行不必要的查询或远程调用。
- 使用
SELECT ... FOR UPDATE NOWAIT：在明确需要锁定的场景，使用NOWAIT选项。如果锁无法立即获得，它会立刻报错而不是等待，由应用程序决定重试或转向其他逻辑，从而避免形成等待环。 - 设置锁超时：在达梦数据库中，可以通过设置会话或系统级的
LOCK_TIMEOUT参数，让锁等待在超过指定时间后自动超时并报错，这也能有效预防死锁的永久挂起。
最后，将本次事件中使用的诊断SQL、分析过程和根本原因整理成文档，纳入团队的运维知识库。甚至可以将其封装成自动化脚本或监控面板，当下次告警再次响起时，你就能更加从容不迫。处理死锁的快慢，往往不取决于手速，而取决于预案的完备程度。