导读：慢查询是数据库性能问题的常见根源。本文将带你从零开始，完成达梦数据库慢查询日志的配置、慢 SQL 的制造与捕获，以及使用 DMLOG 工具进行慢查询分析的全流程实践。

为什么需要慢查询日志？

在数据库运维中，慢查询日志是性能诊断的第一道防线。通过记录执行时间超过设定阈值的 SQL 语句，我们可以：

作用	说明
定位性能瓶颈	找出拖慢系统的“罪魁祸首”SQL
优化索引设计	针对慢查询创建或调整索引
改善用户体验	缩短应用响应时间
容量规划参考	分析高频 SQL 的耗时趋势

达梦数据库提供了完整的慢查询日志解决方案：SVR_LOG 参数负责开启日志功能，sqllog.ini 控制记录规则，DMLOG 工具则负责将原始日志解析为可读的分析报告。

一、开启 SQL 日志总开关

SVR_LOG 属于动态参数，修改后立即生效，无需重启数据库：

SP_SET_PARA_VALUE(1, 'SVR_LOG', 1);

💡 参数说明：SVR_LOG=0 表示关闭日志，SVR_LOG=1 表示开启日志。参数值 1 表示同时修改当前运行值和配置文件，立即生效。

二、精细配置 sqllog.ini

SVR_LOG 是总开关，而 sqllog.ini 则是控制“记什么、记多久、怎么记”的规则引擎。

配置示例：

sqllog.ini 里有几个不同的日志记录器（SLOG），各自负责记录不同类型的 SQL：

配置节	用途	MIN_EXEC_TIME	说明
[SLOG_ALL]	记录所有 SQL	0	记录所有执行的 SQL（无时间过滤）
[SLOG_ERROR]	记录错误 SQL	—	只记录执行出错的 SQL
[SLOG_DDL]	记录 DDL 语句	—	记录建表、删表等结构变更
[SLOG_LONG_SQL]	记录慢查询	60000	只记录执行超过 60 秒的 SQL

为了验证慢查询，修改参数为1000毫秒

参数	当前值	修改为	说明
MIN_EXEC_TIME	60000	1000	只记录执行时间超过 1000 毫秒的 SQL

让配置生效

修改 sqllog.ini 后，执行以下命令使配置立即生效（无需重启数据库）：

SP_REFRESH_SVR_LOG_CONFIG();

三、制造慢查询

当前数据量较小时，普通查询难以触发慢查询阈值。我们通过批量插入 100000 条 测试数据来制造慢查询：

BEGIN
  FOR i IN 1..100000 LOOP
    INSERT INTO transport_orders(order_id, customer_name, order_date, total_amount, status)
    VALUES (100000 + i, '客户' || i, SYSDATE - MOD(i, 30), MOD(i, 9999) + 1, 'P');
  END LOOP;
  COMMIT;
END;

执行结果：

项目	值
执行耗时	3127 ms（约 3.1 秒）
慢查询阈值	1000 ms
是否触发慢查询	✅ 是（3127 > 1000）

此时日志文件已记录该条慢查询，等待后续工具分析。

四、DMLOG 工具安装与配置

DMLOG 是达梦官方提供的轻量化 SQL 日志分析工具，可将原始的 SQL 日志文件解析为结构化的慢查询报告，支持：

✅ 按执行时间筛选慢 SQL

✅ 按执行次数排序

✅ 导出 Excel 报表

✅ 生成 QPS 趋势图表

配置文件 dmlog.properties：

运行 DMLOG：

cd /d E:\dmdb\tool\DMLOG8.182
java -jar Dmlog_DM_8.182.jar

五、分析结果解读

DMLOG 在 RESULT_* 目录下生成多个结果文件：

文件	内容
more_than_1000_ms_log_result.xls	慢查询列表（执行时间 > 1 秒的 SQL）
more_than_0_times_log_result.xls	全量 SQL 执行次数统计
echarts_qps.html	QPS 趋势图

6.1 捕获的慢查询

SQL 类型	执行耗时（ms）	执行用户	日志来源
INSERT（批量插入 100000 条）	3127.0	TRANS_USER	dmsql_DMSERVER32_20260731_142403.log

6.2 慢查询优化建议

优化方向	建议
批量操作拆分	将单次 10 万条插入拆分为多次小批量（如每次 1 万条）
日志缓冲区优化	考虑调整 LOG_BUFFER 参数，减少日志刷盘等待
执行时间窗口	大批量数据操作安排在业务低峰期执行