达梦数据库优化实战：从政务系统案例看索引设计与SQL改写

在政务信息化系统中，数据库性能往往直接关系到民生服务的响应速度和用户体验。某省级政务服务平台曾面临这样的困境：当市民同时在线提交大量申请时，关键查询响应时间从平日的毫秒级骤升至5秒以上，导致系统界面卡顿、操作超时。经过深入排查，发现问题根源在于数据库索引设计不合理和SQL语句未优化。本文将基于该真实案例，拆解达梦数据库性能优化的完整解决路径。

1. 政务系统典型性能问题诊断

该政务系统核心表t_apply存储了近3年的行政审批数据，总量超过2000万条。在业务高峰期，以下两类查询成为性能瓶颈：

1. 按时间段统计查询：各级部门需要实时查看当日/当月申请量统计
2. 多条件组合查询：窗口工作人员需要按"部门ID+申请状态+提交时间"组合条件快速定位申请记录

通过达梦数据库自带的监控视图，我们发现存在以下问题特征：

-- 查看活跃会话中的高耗时SQL
SELECT sess_id, sql_text, elapsed_time/1000 "耗时(秒)" 
FROM v$sessions 
WHERE state='ACTIVE' AND elapsed_time>300000
ORDER BY elapsed_time DESC;

典型问题SQL的执行计划显示存在全表扫描：

1   #NSET2: [5200, 1, 186]
2     #PRJT2: [5200, 1, 186]
3       #SLCT2: [5200, 13200, 186]; t_apply.dept_id = 'D001'
4         #CSCN2: [1200, 13200000, 186]; t_apply

关键性能指标对比：

指标	优化前	优化目标
平均响应时间	4800ms	≤300ms
CPU利用率	85%峰值	≤60%
逻辑读次数	12万/次	≤1万/次

2. 复合索引设计的黄金法则

2.1 前导列选择策略

原索引idx_dept_time以部门ID作为前导列，这在数据分布上存在严重问题：

-- 检查列基数（不同值数量）
SELECT 
  COUNT(DISTINCT dept_id) "部门数",
  COUNT(DISTINCT create_time) "时间粒度"
FROM t_apply;

查询结果显示：该表只有20个部门ID，但时间戳精确到毫秒级。根据高筛选度优先原则，我们调整索引列顺序：

-- 低效索引
CREATE INDEX idx_dept_time ON t_apply(dept_id, create_time);

-- 优化后索引
CREATE INDEX idx_time_dept ON t_apply(create_time, dept_id);

索引设计优化前后性能对比：

查询条件	原索引耗时	新索引耗时	扫描行数减少
WHERE create_time > ?	5.2s	0.3s	99.8%
WHERE dept_id = ?	1.8s	2.1s	0%

2.2 覆盖索引优化

对于高频查询SELECT apply_no, status FROM t_apply WHERE create_time BETWEEN ? AND ?，我们采用包含所有查询字段的覆盖索引：

CREATE INDEX idx_cover_apply ON t_apply(create_time, apply_no, status);

这样可以利用索引覆盖扫描避免回表操作：

优化后执行计划：
1   #NSET2: [30, 1200, 60]
2     #PRJT2: [30, 1200, 60]
3       #SSEK2: [30, 1200, 60]; idx_cover_apply(t_apply)

3. 大字段处理的特殊优化

政务系统中常见的材料附件内容存储在CLOB字段中，相关查询需要特殊处理：

3.1 全文索引替代LIKE查询

-- 低效的模糊查询
SELECT * FROM t_apply WHERE content LIKE '%城市规划%';

-- 创建全文索引
CREATE CONTEXT INDEX idx_content ON t_apply(content) SYNC;

-- 优化后查询
SELECT * FROM t_apply WHERE CONTAINS(content, '城市规划');

性能提升对比：

查询类型	平均耗时	资源消耗
LIKE查询	8.7s	高CPU占用
全文检索	0.4s	内存消耗稳定

3.2 大字段分表策略

对于超过1MB的附件内容，建议采用分表存储：

CREATE TABLE t_apply_attachment (
    apply_id VARCHAR(20) PRIMARY KEY,
    meta_info JSON,
    file_content BLOB,
    CONSTRAINT fk_apply FOREIGN KEY(apply_id) REFERENCES t_apply(apply_no)
);

4. SQL改写实战技巧

4.1 分页查询优化

政务系统常见的分页查询从原来的15秒优化到0.2秒：

-- 低效写法（偏移量10万）
SELECT * FROM t_apply ORDER BY create_time DESC LIMIT 100000, 20;

-- 优化方案1：主键定位
SELECT * FROM t_apply 
WHERE create_time < (SELECT create_time FROM t_apply ORDER BY create_time DESC LIMIT 100000, 1)
ORDER BY create_time DESC LIMIT 20;

-- 优化方案2：游标分页（适用于前后翻页）
SELECT * FROM t_apply 
WHERE create_time < :last_page_min_time
ORDER BY create_time DESC LIMIT 20;

4.2 统计查询改写

将实时统计改为预计算+增量更新：

-- 创建统计中间表
CREATE TABLE t_daily_stats (
    stat_date DATE PRIMARY KEY,
    dept_id VARCHAR(10),
    total_count INT,
    pending_count INT
);

-- 使用物化视图自动维护
CREATE MATERIALIZED VIEW mv_daily_stats
REFRESH COMPLETE ON DEMAND
ENABLE QUERY REWRITE
AS
SELECT 
    TRUNC(create_time) stat_date,
    dept_id,
    COUNT(*) total_count,
    SUM(CASE WHEN status='PENDING' THEN 1 ELSE 0 END) pending_count
FROM t_apply
GROUP BY TRUNC(create_time), dept_id;

5. 执行计划深度解析

掌握达梦数据库执行计划解读是优化的基本功：

5.1 关键操作符解读

操作符	含义	优化方向
CSCN2	全表扫描	考虑增加索引
SSEK2	索引扫描	检查索引效率
HAGR2	哈希分组	评估数据倾斜
NEST LOOP	嵌套循环	检查驱动表大小

5.2 ET工具实战

-- 开启监控
SF_SET_SESSION_PARA_VALUE('MONITOR_SQL_EXEC',1);

-- 执行待分析SQL
SELECT * FROM t_apply WHERE create_time > '2025-01-01';

-- 查看ET分析结果
ET(140357593086048);

典型ET报告解读：

OP            TIME(us)  PERCENT
---------------------------------
CSCN2         770000     77.2%   ← 全表扫描瓶颈
SLCT2          43000      4.3%
PRJT2          12000      1.2%
NSET2          18000      1.8%

6. 参数调优与系统配置

根据政务系统特点调整关键参数：

-- 内存配置（32G内存服务器）
ALTER SYSTEM SET 'BUFFER' = 24576 SCOPE=SPFILE;  -- 24GB缓冲池
ALTER SYSTEM SET 'SORT_BUF_SIZE' = 512 SCOPE=SPFILE;  -- 排序区

-- 工作线程配置
ALTER SYSTEM SET 'WORKER_THREADS' = 32 SCOPE=SPFILE;  -- 16核CPU

-- 统计信息收集
DBMS_STATS.GATHER_TABLE_STATS('DMHR','T_APPLY',ESTIMATE_PERCENT=>100);

7. 持续监控体系建立

构建完整的性能监控闭环：

-- 创建监控表
CREATE TABLE mon_sql_perf (
    sql_id BIGINT PRIMARY KEY,
    sql_text TEXT,
    avg_elapsed INT,
    exec_count INT,
    last_capture TIMESTAMP
);

-- 定期捕获慢SQL
INSERT INTO mon_sql_perf
SELECT 
    HASH(sql_text),
    sql_text, 
    AVG(elapsed_time),
    COUNT(*),
    SYSDATE
FROM v$sql_history
WHERE elapsed_time > 300000
GROUP BY HASH(sql_text), sql_text;

结合达梦数据库管理工具，可以设置自动告警规则：

• CPU持续>70%超过5分钟
• 单SQL执行时间>3秒
• 锁等待数量>10

在政务系统实际优化过程中，通过上述组合策略，最终使系统在业务高峰期的主要查询响应时间控制在300毫秒内，CPU峰值负载从85%降至55%，成功支撑了日均20万+的行政审批业务处理。这印证了达梦数据库在关键业务系统中通过合理优化可以达到媲美国际主流数据库的性能表现。