达梦数据库 DM8 性能调优方案与 AI（ChatGPT 5.x）辅助实践

适用读者：有一定 DM8 基础的 DBA / 开发，期望系统性做好性能调优，并学会用 AI 做“第二个 DBA 同事”。

1. 调优总体思路

可以按“四层”来拆解 DM8 性能问题：

硬件与操作系统层：CPU、内存、磁盘阵列、RAID、文件系统、I/O 调度等。
数据库实例层（dm.ini / 运行参数）：连接数、缓冲区、HASH/排序缓存、线程数等。
SQL 与结构设计层：索引设计、SQL 写法、事务长度、锁冲突等。
业务与访问模式层：高并发短事务 / 批处理 / 报表等，影响参数取值与索引策略。

调优步骤建议： - 先确认“瓶颈在哪一层”，不要盲目改参数； - 先保证正确性与稳定性，再追求极致性能； - 所有调整先在测试环境回放 / 回归，再上线。

2. DM8 关键监控视图与工具

在 disql 中常用：

-- 实例参数（dm.ini 与运行时参数）
SELECT * FROM V$DM_INI;

-- 会话与连接
SELECT SID, USER_NAME, SQL_TEXT, STATE
  FROM V$SESSION;

-- 等待事件/锁情况（示例视图名，按实际版本调整）
SELECT * FROM V$LOCK;        -- 锁等待
SELECT * FROM V$WAITSUMMARY; -- 等待统计（部分版本）

-- SQL 统计（不同版本可能略有差异）
SELECT * FROM V$SQLAREA;

常用命令行工具： - disql：命令行客户端 - dmrman：物理备份与恢复 - dexp / dimp：逻辑导出导入

3. 实例参数调优：内存与连接

3.1 快速查看关键参数

-- 常见关键参数快速查看
SELECT 'MAX_SESSIONS' PARA, SF_GET_PARA_VALUE(1,'MAX_SESSIONS') AS VAL FROM DUAL
UNION ALL
SELECT 'MAX_SESSION_STATEMENT', SF_GET_PARA_VALUE(1,'MAX_SESSION_STATEMENT') FROM DUAL
UNION ALL
SELECT 'MAX_OS_MEMORY', SF_GET_PARA_VALUE(1,'MAX_OS_MEMORY') FROM DUAL
UNION ALL
SELECT 'BUFFER', SF_GET_PARA_VALUE(1,'BUFFER') FROM DUAL
UNION ALL
SELECT 'RECYCLE', SF_GET_PARA_VALUE(1,'RECYCLE') FROM DUAL
UNION ALL
SELECT 'HJ_BUF_GLOBAL_SIZE', SF_GET_PARA_VALUE(1,'HJ_BUF_GLOBAL_SIZE') FROM DUAL
UNION ALL
SELECT 'CACHE_POOL_SIZE', SF_GET_PARA_VALUE(1,'CACHE_POOL_SIZE') FROM DUAL
UNION ALL
SELECT 'WORKER_THREADS', SF_GET_PARA_VALUE(1,'WORKER_THREADS') FROM DUAL
UNION ALL
SELECT 'TASK_THREADS', SF_GET_PARA_VALUE(1,'TASK_THREADS') FROM DUAL;

说明：SF_GET_PARA_VALUE(1, ...) 表示从 dm.ini 配置文件获取参数值；2 表示当前内存中的运行值。

3.2 调整参数的一般方法

DM8 支持通过存储过程修改参数：

-- 通用形式
CALL SP_SET_PARA_VALUE(2, '参数名', 数值);     -- 写 dm.ini，重启后生效或部分参数立即生效
CALL SF_SET_SYSTEM_PARA_VALUE('参数名', 数值, 1, 2);

常见调整方向（需结合物理内存、并发量）：

连接数
MAX_SESSIONS：允许的最大会话数，受 License 限制；OLTP 系统可考虑按峰值并发 × 1.5~2 设置。
MAX_SESSION_STATEMENT：单会话可同时打开的语句句柄数，一般从默认 100 提升到 1000~5000 之间。
内存与缓冲区（单位 MB，以下仅为思路示例）
MAX_OS_MEMORY：DM 使用的内存占 OS 总内存百分比，建议 70~90 之间。
BUFFER：数据缓冲区，推荐约等于可用物理内存的 60~80%。
RECYCLE：回收缓冲区，用于冷数据，可略小于 BUFFER。
HJ_BUF_GLOBAL_SIZE / HJ_BUF_SIZE：哈希连接缓存，报表/汇总多时可适当增大。
CACHE_POOL_SIZE：SQL 计划缓存池，SQL 种类多、重复率高的系统可适当增大。
线程类参数
WORKER_THREADS：工作线程数，通常设置为 CPU 逻辑核心数的 60%~80%。
TASK_THREADS：任务线程数，结合并行任务、批处理数量调整。

示例（假设 64GB 物理内存，OLTP+轻报表）：

CALL SP_SET_PARA_VALUE(2, 'MAX_SESSIONS', 3000);
CALL SP_SET_PARA_VALUE(2, 'MAX_SESSION_STATEMENT', 5000);
CALL SP_SET_PARA_VALUE(2, 'MAX_OS_MEMORY', 85);
CALL SP_SET_PARA_VALUE(2, 'BUFFER', 32000);
CALL SP_SET_PARA_VALUE(2, 'RECYCLE', 8000);
CALL SP_SET_PARA_VALUE(2, 'HJ_BUF_GLOBAL_SIZE', 4000);
CALL SP_SET_PARA_VALUE(2, 'CACHE_POOL_SIZE', 512);
CALL SP_SET_PARA_VALUE(2, 'WORKER_THREADS', 24);
CALL SP_SET_PARA_VALUE(2, 'TASK_THREADS', 24);

注意：以上数值仅为示意，请根据实际硬件、业务压力与官方文档再确认。

4. SQL 与索引调优

4.1 找到“最慢的那一批 SQL”

思路：按执行次数、平均响应时间、逻辑读、物理读等维度排序，找 Top SQL。

-- 示例：按平均执行时间排序 Top SQL（字段名可根据版本调整）
SELECT SQL_TEXT, EXECUTIONS, ELAPSED_TIME, ELAPSED_TIME/EXECUTIONS AVG_ELAPSED
  FROM V$SQLAREA
 WHERE EXECUTIONS > 100
 ORDER BY AVG_ELAPSED DESC
 FETCH FIRST 50 ROWS ONLY;

4.2 查看执行计划

EXPLAIN SELECT ... FROM ... WHERE ...;

-- 部分版本可以使用
SELECT * FROM V$PLAN;  -- 查看最近一次 EXPLAIN 的计划

关注要点： - 是否存在大表 全表扫描 却缺乏合适索引； - 是否出现频繁的 HASH JOIN / NESTED LOOP 对大数据量表，导致内存与 I/O 压力； - 是否存在大量排序、临时表空间使用（注意 TEMP_SIZE、临时表空间使用率）。

4.3 常见 SQL 优化手段

避免在索引列上使用函数 / 模糊前缀匹配，影响索引利用；
用合适的 联合索引 与 覆盖索引 减少回表；
控制大事务，拆分为小批次提交，减少锁等待；
使用绑定变量减少硬解析次数，提高计划缓存命中。

5. 结合 AI（ChatGPT 5.x）进行调优

AI 可以在调优中扮演“有经验的同事”，但前提是： - 严格脱敏：不要直接上传敏感表名、列名、业务数据； - 在你自己有基本判断的前提下，使用 AI 做“第二意见”和文档生成器。

5.1 适合交给 ChatGPT 的任务

阅读与总结信息：
把 V$DM_INI、V$SQLAREA、EXPLAIN 输出做适当整理后贴给 AI，请它总结：
- 目前参数是否存在明显不合理的地方；
- 哪些 SQL 最值得优先优化；
- 执行计划中有哪些典型问题。
给出备选调优方案：
让 AI 结合你的硬件配置、业务特点（OLTP/报表），给出一组候选参数与解释。
让 AI 生成“试验方案与回滚方案”文档，便于变更评审。
自动生成脚本与文档：
生成查询 Top SQL 的视图/脚本；
生成标准化的巡检报告模板；
帮你把一次调优过程整理成运维文档。

5.2 示例 Prompt：参数调优

你可以按下面模板向 ChatGPT 提问（注意脱敏与概括）：

“你是熟悉达梦 DM8 的数据库专家。现在有一套系统，硬件配置大致如下： - CPU：16C 32G - 存储：SSD，主要是 OLTP 业务，少量报表。

以下是我从 DM8 中导出的部分参数（单位如无特别说明都是 MB）：

MAX_SESSIONS=...
MAX_SESSION_STATEMENT=...
MAX_OS_MEMORY=...
BUFFER=...
RECYCLE=...
HJ_BUF_GLOBAL_SIZE=...
CACHE_POOL_SIZE=...
WORKER_THREADS=...
TASK_THREADS=...

请你： 1. 说明这些参数分别对性能有什么影响； 2. 结合我的硬件和 OLTP+少量报表场景，给出一套更合理的参数建议，并解释每个参数为何这样取值； 3. 给出一个分阶段调整方案（例如先调整哪些，观察哪些指标，再调整哪些）； 4. 顺便给一段 DM8 的 SQL/存储过程代码，方便我直接在测试环境执行这些调整。”

5.3 示例 Prompt：SQL 与索引调优

你可以把 Top SQL 与执行计划摘要整理为文本：

SQL1: 查询订单汇总 ...（略）
执行次数：20万次/小时
平均响应时间：120ms
执行计划：大表 ORDER 明显全表扫描，连接 CUSTOMER 时走 HASH JOIN ...

SQL2: ...

然后向 ChatGPT 提问：

“请帮我逐条分析这些 SQL 的性能问题，给出： 1. 可能需要新增或优化的索引（只写出索引列组合和顺序即可）； 2. 需要调整的 SQL 写法（比如避免函数、改写子查询等）； 3. 可能导致锁等待和临时表空间膨胀的地方； 4. 每条 SQL 的调优优先级排序。”

6. 实战落地建议

固定节奏的巡检与基线
每天/每周固定时间采集：CPU、I/O、主要视图（V$DM_INI、V$SQLAREA、V$SESSION）快照。
把指标输入 ChatGPT，让它帮你画出“趋势”和“异常点说明”。
变更前后对比
所有参数调整、索引变更、SQL 重构，都要有“前后对比”的 TPS/QPS、延时、资源占用数据。
可以让 AI 帮你生成对比报告和结论摘要。
自动化脚本与文档沉淀
把本文中的查询、调优脚本整理成 .sql 文件放入 DBA 工具库；
把与 ChatGPT 的高质量对话整理成“案例库”，方便团队其他人学习。

通过上述思路，你可以在掌控风险的前提下，逐步把 DM8 的性能和稳定性“拉满”，同时把 AI 变成自己的助理 DBA，而不是替代者。