贵州省网站建设_网站建设公司_MySQL_seo优化

在数据库查询优化中，ORDER BY 子句导致的排序操作往往是性能瓶颈之一。当前测试展示如何通过合理的索引设计来消除排序操作，显著提升查询性能。

场景介绍 我们有一个销售表 EMPLOYEE，包含以下字段：

• HIRE_DATE：入职时间
• EMPLOYEE_ID：员工ID
• SALARY：薪水

业务需求：查询最近11 年的员工信息，并按入职时间降序、员工ID 降序排列。

场景一：没有索引

初始查询语句：

select e.HIRE_DATE, e.EMPLOYEE_ID, e.SALARY from DMHR.EMPLOYEE e where e.HIRE_DATE >= trunc(sysdate) - interval '11' year order by e.HIRE_DATE desc, e.EMPLOYEE_ID desc;

查询出的数据：

HIRE_DATE EMPLOYEE_ID SALARY '2015-03-27' 8004 5000 '2015-03-27' 6004 5000

执行计划：

1 #NSET2: [1, 1, 33] 2 #PRJT2: [1, 1, 33]; exp_num(4), is_atom(FALSE) 3 #SORT3: [1, 1, 33]; key_num(2), partition_key_num(0), is_distinct(FALSE), top_flag(0), is_adaptive(0) 4 #SLCT2: [1, 1, 33]; e.HIRE_DATE >= var4 5 #CSCN2: [1, 856, 33]; INDEX33555499(EMPLOYEE as e); btr_scan(1)

场景二：只有一个单列索引

只在 HIRE_DATE 列上创建一个索引：

CREATE INDEX DMHR.IND_HIRE_DATE20251231 ON DMHR.EMPLOYEE("HIRE_DATE" ASC);

执行计划：

1 #NSET2: [1, 1, 33] 2 #PRJT2: [1, 1, 33]; exp_num(4), is_atom(FALSE) 3 #SORT3: [1, 1, 33]; key_num(2), partition_key_num(1), is_distinct(FALSE), top_flag(0), is_adaptive(0) 4 #BLKUP2: [1, 1, 33]; IND_HIRE_DATE20251231(e) 5 #SSEK2: [1, 1, 33]; scan_type(DESC), IND_HIRE_DATE20251231(EMPLOYEE as e), scan_range[exp11,max], is_global(0)

关键发现：上面执行计划中出现了 SORT3 操作符，说明数据库在进行显式排序，可以通过ET 输出，可以判断使用了多少内存(MEM_USED(KB)，DISK_USED(KB))。

第一次优化：创建复合索引

create index IND_HIRE_ID on DMHR.EMPLOYEE(HIRE_DATE, EMPLOYEE_ID);

(删除旧索引后，实际测试没有删除页可以)重新执行查询，执行计划变为：

1 #NSET2: [1, 1, 33] 2 #PRJT2: [1, 1, 33]; exp_num(4), is_atom(FALSE) 3 #BLKUP2: [1, 1, 33]; IND_HIRE_ID(e) 4 #SSEK2: [1, 1, 33]; scan_type(DESC), IND_HIRE_ID(EMPLOYEE as e), scan_range[(exp11,min),(max,max)), is_global(0)

优化效果：SORT3 操作符消失了！数据库通过反向扫描索引直接获得了正确排序的结果。

场景二：混合排序场景

修改查询，要求按入职时间降序、员工ID升序排列：

select e.HIRE_DATE, e.EMPLOYEE_ID, e.SALARY from DMHR.EMPLOYEE e where e.HIRE_DATE >= trunc(sysdate) - interval '11' year order by e.HIRE_DATE desc, e.EMPLOYEE_ID asc;

执行计划：

1 #NSET2: [1, 1, 33] 2 #PRJT2: [1, 1, 33]; exp_num(4), is_atom(FALSE) 3 #SORT3: [1, 1, 33]; key_num(2), partition_key_num(1), is_distinct(FALSE), top_flag(0), is_adaptive(0) 4 #BLKUP2: [1, 1, 33]; IND_HIRE_DATE20251231(e) 5 #SSEK2: [1, 1, 33]; scan_type(DESC), IND_HIRE_DATE20251231(EMPLOYEE as e), scan_range[exp11,max], is_global(0)

问题再现：SORT3 操作符再次出现！虽然使用了复合索引，但排序方向不匹配。

解决方案：匹配排序方向的索引

创建与 ORDER BY 子句完全一致的索引：

create or replace index IND_HIRE_ID on DMHR.EMPLOYEE(HIRE_DATE desc, EMPLOYEE_ID asc);

执行计划：

1 #NSET2: [1, 1, 33] 2 #PRJT2: [1, 1, 33]; exp_num(4), is_atom(FALSE) 3 #BLKUP2: [1, 1, 33]; IND_HIRE_ID(e) 4 #SSEK2: [1, 1, 33]; scan_type(ASC), IND_HIRE_ID(EMPLOYEE as e), scan_range[(null2,min),(exp11,max)), is_global(0)

最终效果：排序再次被消除！这次数据库通过正向扫描特殊设计的索引获得了正确结果。

核心原理总结

1. 索引消除排序的条件

• 当 ORDER BY 的顺序与索引扫描结果的顺序完全一致时，可消除排序
• 数据库可以正向或反向扫描索引来匹配不同的排序需求

2. 不同场景下的匹配规则

ORDER BY 子句 可消除排序的索引 扫描方向 A DESC, B DESC (A ASC, B ASC) 反向扫描 A ASC, B ASC (A ASC, B ASC) 正向扫描 A DESC, B ASC (A DESC, B ASC) 正向扫描

3. 达梦数据库的执行计划关键操作符

• SORT3：显式排序操作，消耗内存和CPU
• SSEK2：索引范围扫描，scan_type 显示扫描方向
• BLKUP2：通过索引回表取数据

实践建议

• 分析执行计划：关注 SORT 操作符的出现，这是优化的信号
• 创建复合索引：将 WHERE 条件和 ORDER BY 的列都考虑进索引
• 匹配排序方向：对于混合排序（ASC/DESC混合），创建对应方向的索引
• 权衡索引数量：虽然专用索引性能最佳，但要考虑维护成本

欢迎访问达梦技术分享社区 ECO

https://eco.dameng.com