达梦 DM8 数据库性能优化技巧分享

达梦数据库（DM8）有着优秀的兼容性和稳定性。但在高并发、大数据量的生产环境中，如何发挥其最大潜能？数据库的性能优化是一门艺术，也是一门科学。本文将从核心参数调整、动态运行监控以及统计信息管理三大核心维度，全面梳理 DM8 的性能优化技巧。

一、核心内存与线程参数调优

DM8 的核心配置主要集中在 dm.ini 文件中。合理的内存和线程分配是数据库高性能运行的底座。参数调整后，通常需要重启数据库或使用动态系统函数使其生效。

1. 调整数据缓冲区 (Data Buffer)

数据缓冲区决定了数据库能在内存中缓存多少数据页，直接影响物理磁盘 I/O 的命中率。在内存充裕的情况下，磁盘 I/O 越少，数据库跑得越快。

关键参数： BUFFER（系统缓冲区大小，单位 MB）。
优化建议： 对于专属的数据库服务器，建议将 BUFFER 配置为物理内存的 60% 到 80%。对于核心的业务表或热点字典数据，可以进一步配合 KEEP 缓冲区或 NORMAL_DICT_CACHE，确保高频查询的数据常驻内存，避免被冷数据置换出局。

-- 调整数据缓冲区（以 8GB 为例）
ALTER SYSTEM SET 'BUFFER' = 8192 SCOPE = SPFILE;

2. 调整 SQL 缓冲区 (SQL Buffer)

当数据库接收到一条 SQL 时，需要经历词法分析、语法分析、生成执行计划等耗时步骤（硬解析）。SQL 缓冲区用于缓存这些执行计划和字典信息。

关键参数： CACHE_POOL_SIZE（SQL 缓存池大小，单位 MB）。
优化建议： 如果系统中存在大量并发的短连接，或者相同的 SQL 频繁执行（尤其是做好了变量绑定的 SQL），适当调大 CACHE_POOL_SIZE 可以大幅提升“软解析”的命中率，显著降低 CPU 负载。一般建议初始设置为 200MB - 1024MB，并根据系统的实际运行情况动态调优。

-- 调整 SQL 缓冲区（以 512MB 为例）
ALTER SYSTEM SET 'CACHE_POOL_SIZE' = 512 SCOPE = SPFILE;

3. 调整工作线程 (Working Threads)

DM8 采用多线程架构，合理的线程分配可以提升并行处理能力，同时减少系统级上下文切换的开销。

关键参数： WORKER_THREADS 和 TASK_THREADS。
优化建议：
- WORKER_THREADS：用于处理客户端发来的实际业务请求。其大小应与 CPU 逻辑核数相匹配。不建议盲目设置过大（通常等于或略大于 CPU 核心数即可），否则反而会导致严重的 CPU 调度竞争。
- TASK_THREADS：用于处理数据库内部的异步任务（如并行建索引、日志刷盘辅助等）。默认配置通常已经足够，但在夜间执行大规模批处理或并行备份时，可结合物理机的资源空闲情况酌情增加。

-- 调整工作线程与任务线程（以 16 核 CPU 为例）
ALTER SYSTEM SET 'WORKER_THREADS' = 16 SCOPE = SPFILE;
ALTER SYSTEM SET 'TASK_THREADS' = 8 SCOPE = SPFILE;

二、动态监控与排障介入

再好的初始配置也无法应对多变的业务形态。通过 DM8 的动态性能视图，我们可以精准定位性能瓶颈。

1. 长耗时 SQL 监控

低效的“慢 SQL”是拖垮数据库性能的头号杀手。主动捕获并优化它们是 DBA 的日常核心工作。

监控前提： 请确保在 dm.ini 中开启了监控开关（ENABLE_MONITOR = 1 且 MONITOR_TIME = 1）。

核心视图： V$LONG_EXEC_SQLS。该视图会自动记录执行时间超过阈值的 SQL。

-- 开启监控开关并设置慢 SQL 阈值（如超过 500 毫秒）
CALL SF_SET_SYSTEM_PARA_VALUE('ENABLE_MONITOR', 1, 1, 1);
CALL SF_SET_SYSTEM_PARA_VALUE('MONITOR_TIME', 1, 1, 1);
CALL SF_SET_SYSTEM_PARA_VALUE('LONG_SQL_TIME', 500, 1, 1);

-- 查询执行时间超过阈值的 SQL
SELECT 
    EXEC_TIME,     -- 执行时长（毫秒）
    SQL_TEXT,      -- SQL 文本内容
    SESS_ID,       -- 执行该 SQL 的会话 ID
    USER_NAME      -- 执行用户
FROM 
    V$LONG_EXEC_SQLS 
ORDER BY 
    EXEC_TIME DESC;

操作步骤： 提取耗时异常的 SQL_TEXT，使用 EXPLAIN 查看其执行计划。重点排查是否缺少关键索引、是否发生了全表扫描、或者多表联查时连接顺序错误（如本该做 Hash Join 却走了 Nested Loop）。

2. 会话监控

当系统出现突然卡顿、应用报错锁等待，或是连接池耗尽时，会话监控是定位问题的第一入口。

核心视图： V$SESSIONS。

-- 查询阻塞会话
SELECT 
    SESS_ID, 
    STATE,         -- 会话状态（ACTIVE 表示正在执行，IDLE 表示空闲等待）
    USER_NAME, 
    CLNT_IP,       -- 客户端来源 IP
    TRX_ID         -- 当前持有的事务 ID
FROM 
    V$SESSIONS 
WHERE 
    STATE = 'ACTIVE';
    
-- 强行关闭指定的异常或阻塞会话
CALL SP_CLOSE_SESSION(会话ID);

操作步骤： 重点关注 STATE 为 ACTIVE 且运行时间极长的会话。如果是应用端发起的长事务未提交导致了阻塞，可结合 V$LOCK 视图查出锁源头。对于确实卡死且影响生产的会话，可以使用 SP_CLOSE_SESSION(SESS_ID) 过程将其安全终止。

三、优化器基石：统计信息与直方图

DM8 默认使用基于代价的优化器（CBO）。CBO 就像是一个导航软件，它能否规划出最快路线（最优执行计划），完全取决于它掌握的路况信息（统计信息）是否准确。

1. 收集统计信息

当表中的数据经历了频繁的增删改（尤其是 DML 数据量变动超过 20% 时），旧的统计信息就会过时，导致优化器做出错误判断。

如何操作： DM8 提供了强大的 DBMS_STATS 系统包来进行信息采集。

-- 收集单张表的统计信息示例（全表采样，列直方图自动判定）
CALL DBMS_STATS.GATHER_TABLE_STATS(
    '模式名', 
    '表名', 
    NULL, 
    100,      -- 采样率，小表建议 100% 全采，超大表可适当降低比例
    TRUE, 
    'FOR ALL COLUMNS SIZE AUTO'
);

维护策略： 强烈建议在业务低峰期（如凌晨）配置系统的 Job 定时任务，自动扫描并更新核心业务表的统计信息。

2. 数据倾斜：直方图 (Histogram)

优化器在没有直方图时，会默认某列的数据在最大值和最小值之间是均匀分布的。但在现实业务中，数据倾斜（Data Skew）比比皆是。例如电商订单的状态列，95% 是“已完成”，只有 5% 是“退款中”。

为什么需要直方图： 如果查询“已完成”的订单，全表扫描往往比走索引更快；如果查询“退款中”的订单，走索引才是最优解。直方图就是用来向优化器描述这种列数据的分布不均情况的。
频率直方图 vs 等高直方图： DM8 支持这两种直方图。当该列的不同值（NDV）较少时使用频率直方图；当不同值极多时，数据库会将其分桶（Bucket），使用等高直方图。
无感触发机制： 在上面收集统计信息的代码中，METHOD_OPT 参数被设置为 'FOR ALL COLUMNS SIZE AUTO'。DM8 的优化器会根据列的数据分布特征以及曾经的查询负载，自动决定是否需要为倾斜列收集直方图，极大降低了 DBA 的手动维护成本。

-- 显式为数据倾斜列收集直方图（指定 20 个桶）
CALL DBMS_STATS.GATHER_TABLE_STATS(
    '模式名', 
    '表名', 
    METHOD_OPT => 'FOR COLUMNS 列名 SIZE 20'
);

总结

DM8 的性能调优需要根据系统环境随机应变，从底层的 参数配置拦截性能瓶颈，到中层的动态监控视图实时排雷，再到上层依靠统计信息和直方图为优化器指引方向，这三者环环相扣。养成定期巡检系统和维持统计信息的习惯，才能让达梦数据库在严苛的生产环境中依然稳定运行。