1 性能诊断与优化总体方法

性能问题的本质通常不是“数据库慢”这一单一结论，而是 CPU、内存、磁盘 I/O、网络、并发、锁等待、SQL 执行计划、统计信息、参数配置或架构选择中的某一环节出现了瓶颈。达梦官方将性能诊断划分为系统资源、动态视图、跟踪日志、AWR、接口等方向；性能优化则聚焦架构、参数、SQL 和统计信息。

定位慢 SQL 是 SQL 优化第一步；高频、单次并不特别慢但总消耗巨大的 SQL，在高并发场景往往比低频长 SQL 更应优先处理。

2 性能诊断前的现场信息收集

在调整任何参数或 SQL 之前，应先建立现场基线。官方建议同时收集硬件、软件与业务变化信息。

SELECT * FROM V$VERSION;
SELECT COUNT(*) FROM V$SESSIONS;
SELECT COUNT(*) FROM V$TRX;
SELECT * FROM V$TRXWAIT;

3 操作系统资源诊断

3.1 内存

Linux 下不能仅依据 free 内存判断“内存不够”。需要结合 swap 的换入换出、cache 等指标判断压力。

vmstat 1 5

3.2 CPU

CPU 分析的关键是把“CPU 忙”进一步拆为用户态、内核态、I/O 等待、运行队列和上下文切换。官方给出了以下观察方法。

sar -u 1 5
sar -q 1 5
top
ps -auxw | more
strace <PID>

3.3 磁盘 I/O

I/O 问题通常需要从“吞吐、延迟、队列、设备繁忙度”四个维度判断，而不是只看读写带宽。

iostat -d -x -k 1 5
iostat -x 1 5
iotop

提示：官方文档给出 await 低于约 5 ms、超过 10 ms 需要重点关注的示例性判断，但实际阈值应依据磁盘介质、阵列、云盘和业务 SLA 建立基线。

3.4 网络

4 达梦动态视图诊断

官方将常见动态视图诊断归纳为：活动会话、长时间执行 SQL、锁、阻塞。实际排障时建议把它们串成一条证据链：并发高 → 哪些会话活跃 → 哪些 SQL 慢 → 是否等待锁 → 谁是阻塞源。

4.1 活动会话

SELECT
(SELECT COUNT(*) FROM V$SESSIONS
WHERE STATE='ACTIVE' AND SESS_ID != SESSID()) ACT_SES,
(SELECT COUNT(*) FROM V$SESSIONS) TOT_SES;

4.2 查找执行超过 2 秒的活动 SQL

SELECT * FROM (
SELECT SESS_ID, SQL_TEXT, STATE,
DATEDIFF(SS,LAST_RECV_TIME,SYSDATE) Y_EXETIME,
TO_CHAR(SF_GET_SESSION_SQL(SESS_ID)) FULLSQL,
CLNT_IP
FROM V$SESSIONS WHERE STATE='ACTIVE'
) WHERE Y_EXETIME>=2;

4.3 锁与阻塞

SELECT O.NAME,L.* FROM V$LOCK L,SYSOBJECTS O WHERE L.TABLE_ID=O.ID AND BLOCKED=1;

阻塞问题的核心不是简单“杀掉一个会话”，而是先识别阻塞事务、被阻塞事务、SQL、客户端以及持续时间，再判断业务上应提交、回滚还是终止会话。

5 SQL 跟踪日志与接口日志诊断

5.1 SQL 跟踪日志

SQL 日志可以记录会话执行 SQL、参数、错误、执行时间等信息。官方方式是通过 SVR_LOG 启用 sqllog.ini，再按需设置日志掩码、慢 SQL 阈值和文件轮转。

SP_SET_PARA_VALUE(1,'SVR_LOG',1);
SP_REFRESH_SVR_LOG_CONFIG();

[SLOG_ALL]
FILE_PATH = ../log
SWITCH_MODE = 1
SWITCH_LIMIT = 100000
ASYNC_FLUSH = 1
FILE_NUM = 200
SQL_TRACE_MASK = 2:3:23:24:25
MIN_EXEC_TIME = 0

提示：日志属于诊断工具，开启范围越广、记录越细，对性能和磁盘空间的影响越大。排障结束后应恢复到合适的日志级别。

5.2 DMLOG

当需要系统汇总分析 SQL 日志时，官方提供 DMLOG，用于按 SQL 分类、统计执行情况，适合从海量日志中筛选慢 SQL 与高频 SQL。

5.3 JDBC / DPI / DCI / ODBC 接口日志

接口日志适合定位“数据库本身正常，但应用侧表现异常”的场景，包括连接问题、SQL 执行信息、错误以及状态监控。JDBC 可通过 logDir、logLevel、logFlushFreq、statEnable、statDir、statFlushFreq、statSlowSqlCount、statHighFreqSqlCount 等属性控制。

6 数据库架构优化

架构优化的核心原则是：先判断瓶颈是单机资源不足、读压力集中、存储瓶颈还是数据规模增长，再决定是否需要从架构层解决。单纯调参数无法替代错误的架构选型。

7 数据库参数优化

7.1 关键内存/执行相关参数

7.2 参数修改方式

-- 系统级修改
ALTER SYSTEM SET '<参数名称>'=<参数值> [DEFERRED] [MEMORY|BOTH|SPFILE];

-- 会话级修改
ALTER SESSION SET '<参数名称>'=<参数值> [PURGE];

-- 查看参数
SELECT * FROM V$DM_INI WHERE PARA_NAME LIKE 'PK_WITH%';
SELECT * FROM V$PARAMETER WHERE NAME LIKE 'PK_WITH%';

提示：静态参数、动态参数和会话参数的生效范围不同。生产环境修改前应确认版本、参数属性、当前值、目标值、是否需要重启，以及回滚方式。

8 SQL 性能定位与执行计划

8.1 慢 SQL 的优先级

单次几十秒但一天执行很少的 SQL，可能不是第一优先级；单次几百毫秒但每秒执行上百次的高频 SQL，总消耗可能更大。优化应以“总资源消耗 × 业务影响”为优先级。

8.2 EXPLAIN

EXPLAIN SELECT * FROM SYSOBJECTS;

达梦执行计划每行是一个节点，常见信息可理解为：操作符 + [代价、估算行数、估算字节数] + 补充信息。执行顺序可用“最右最上先执行”快速理解，即缩进更深的节点通常更先执行。

8.3 执行计划应该怎么看

• 第一看：基数估算是否离谱。估算行数与实际返回行数差距大，优先怀疑统计信息。
• 第二看：扫描方式。大表是否出现不必要的全表扫描；索引是否使用，是否发生大量回表。
• 第三看：连接顺序和连接算法。OLTP 常见小表驱动大表；HASH JOIN、MERGE JOIN 是否与数据量和排序状态匹配。
• 第四看：排序、分组、临时空间。ORDER BY、GROUP BY、UNION 等可能引入排序/临时表开销。
• 第五看：并发环境下是否存在“单条 SQL 不慢但叠加后很慢”的情况。

9 SQL 语句与索引优化

9.1 通用原则

• 减少 SQL 执行期间的 I/O、内存计算和临时空间使用。
• 减少不必要的返回结果集，分页查询尤其需要关注排序与大结果集。
• 合理设计组合索引，兼顾查询收益与 DML 维护成本。
• 关注连接条件与表规模，小表驱动大表并非绝对规则，但在适合嵌套循环连接的 OLTP 场景中常常重要。

9.2 索引适用与失效

提示：“是否使用索引”不是越多越好，而是由选择性、访问路径、回表代价、统计信息和连接方式共同决定。

9.3 常见 SQL 改写

① GROUP BY 前先过滤，尽可能缩小参与聚集的数据集。

-- 优化前
SELECT JOB, AVG(AGE) FROM TEMP
GROUP BY JOB HAVING JOB='STUDENT' OR JOB='MANAGER';

-- 优化后
SELECT JOB, AVG(AGE) FROM TEMP
WHERE JOB='STUDENT' OR JOB='MANAGER' GROUP BY JOB;

② 业务允许时用 UNION ALL 替换 UNION，避免为了去重而额外排序。

SELECT USER_ID,BILL_ID FROM USER_TAB1 WHERE AGE='20'
UNION ALL
SELECT USER_ID,BILL_ID FROM USER_TAB2 WHERE AGE='20';

③ 一对多查询中，业务目标是“判断是否存在”时，可考虑 EXISTS 替代 DISTINCT。

SELECT USER_ID,BILL_ID FROM USER_TAB1 D
WHERE EXISTS (SELECT 1 FROM USER_TAB2 E WHERE E.USER_ID=D.USER_ID);

④ 事务设计应避免无边界的大事务。官方文档指出 COMMIT 会释放回滚段恢复信息、锁、redo log buffer 等相关资源；但 COMMIT 频率必须根据业务一致性要求设计，不能为了“快”而破坏事务语义。

10 表设计、分区与临时表优化

10.1 水平分区

分区的主要收益是减少访问数据，并允许按分区进行 truncate、drop、add、exchange 等操作。分区并不是天然更快：如果普通表上存在非常合适的索引，普通表可能仍然优于分区表。

10.2 全局临时表

全局临时表用于保存事务或会话期间的中间数据。DM 支持事务级 ON COMMIT DELETE ROWS 和会话级 ON COMMIT PRESERVE ROWS。其优点包括不同 session 数据独立、自动清理。

11 Hint、ET 与 DBMS_SQLTUNE

11.1 ET 性能分析

ET 可以统计 SQL 每个操作符的实际开销，适合回答“到底是哪一个计划节点最耗时”。官方说明 ET 默认关闭，可通过 ENABLE_MONITOR 和 MONITOR_SQL_EXEC 开启。

SP_SET_PARA_VALUE(1,'ENABLE_MONITOR',1);
SP_SET_PARA_VALUE(1,'MONITOR_SQL_EXEC',1);
-- 当前会话
SF_SET_SESSION_PARA_VALUE('MONITOR_SQL_EXEC',1);
-- 查看执行号对应结果
CALL ET(55);

提示：ET 会带来额外开销；完成调优后应根据版本和业务情况关闭不必要的监控。

11.2 DBMS_SQLTUNE

DBMS_SQLTUNE 可以实时观察 SQL 执行时间、代价、执行用户、统计信息等，并能看到真实执行计划、I/O 量、各操作符时间和执行次数；部分场景还可提供索引或统计信息建议。

ALTER SESSION SET 'MONITOR_SQL_EXEC' = 1;
-- 执行待分析 SQL
SELECT DBMS_SQLTUNE.REPORT_SQL_MONITOR(SQL_EXEC_ID=>1213701) FROM DUAL;

11.3 Hint

当统计信息已收集、索引也合理建立，但优化器计划仍不符合预期，可以在明确理解后使用 Hint。Hint 更适合作为特定场景或应急手段，不应替代基础的统计信息、索引和 SQL 设计优化。

SELECT /*+ VIEW_FILTER_MERGING(1) */ * FROM dms.view_da_base WHERE ahdm='...';

12 统计信息管理

统计信息记录表和索引的数据规模与分布特征，是 CBO 估算代价和选择执行计划的重要依据。统计信息失真时，可能导致错误的驱动表、连接方式以及索引选择。

12.1 手动收集

-- Schema 统计信息
DBMS_STATS.GATHER_SCHEMA_STATS('username',100,TRUE,'FOR ALL COLUMNS SIZE AUTO');

-- 单个索引
DBMS_STATS.GATHER_INDEX_STATS('username','IDX_T2_X');

-- 单表
DBMS_STATS.GATHER_TABLE_STATS('username','table_name',NULL,100,TRUE,'FOR ALL COLUMNS SIZE AUTO');

-- 单列
STAT 100 ON table_name(column_name);

提示：统计信息收集本身会消耗数据库资源，官方明确建议避免在业务高峰期执行。

12.2 自动收集

-- 监控表数据变化
SP_SET_PARA_VALUE(1,'AUTO_STAT_OBJ',2);

-- 数据变化超过阈值后触发更新
DBMS_STATS.SET_TABLE_PREFS('SYSDBA','T','STALE_PERCENT',15);

-- 创建自动统计信息触发器
SP_CREATE_AUTO_STAT_TRIGGER(1,1,1,1,'14:36','2020/3/31',60,1);

12.3 查看统计信息

DBMS_STATS.TABLE_STATS_SHOW('模式名','表名');
DBMS_STATS.INDEX_STATS_SHOW('模式名','索引名');
DBMS_STATS.COLUMN_STATS_SHOW('模式名','表名','列名');

13 生产环境标准优化流程

建议把性能问题处理固化为“七步法”，避免一上来就改参数或建索引。

13.1 典型案例：CPU 高

检查 top/sar → 判断 us/sy/wa → 找高 CPU 进程 → 回到数据库定位高消耗 SQL → EXPLAIN/ET → 优化 SQL、索引、并发或应用逻辑 → 回归。

13.2 典型案例：I/O 高

iostat 看 await、avgqu-sz、%util → pidstat/iotop 定位进程 → 数据库确认是否大量全表扫描/排序/回表 → SQL/索引/分区/缓存优化 → 验证。

13.3 典型案例：大量会话卡住

先看 ACTIVE/TOTAL → 查长 SQL → 查 V$LOCK 与阻塞 → 找阻塞源事务 → 核查业务是否存在长事务、未提交事务或不合理锁粒度 → 处理阻塞源。

13.4 典型案例：SQL 计划突然变差

对比历史计划 → 检查表数据规模变化 → 检查统计信息是否过期/失真 → 查看索引状态与选择性 → 重新收集统计信息并验证 → 必要时再考虑 Hint 或参数。

14 常用命令与 SQL 速查表

附录 故障现象 → 证据 → 优化动作对照表