学习笔记：索引手册规范与初次实操

索引作为关系型数据库中控制 I/O 和优化检索的核心机制，其底层原理（如 B 树平衡、代价模型估算、最左匹配原则等）在各大数据库之间大多相通。不过此前主要在 PG / openGauss 生态下工作，转到达梦后，其在对象管理体系、物理存储规划以及数据字典的设计上更偏向 Oracle 体系。

达梦索引分类体系速览

通读手册内容，DM 对索引类型的划分比较系统，日常使用中相对高频的有以下几类：

聚集索引与非聚集索引
- 聚集索引：数据行的物理存储顺序与索引键值严格一致，因此每张表仅能存在一个聚集索引。建表指定主键且未显式指定非聚簇时，DM 默认会将主键绑定为聚集索引。
- 非聚集索引：索引结构独立于数据行物理存储，叶子节点存储键值和行指针（ROWID）。与习惯通过全表扫描或二次索引回表的思路一致，业务维度的大部分检索需求也是通过建立非聚集索引来满足。
功能索引
- 函数索引：业务查询中若包含表达式转换（如大写转换、时间格式截取等），普通索引往往无法生效，需要显式创建基于函数的索引以避免全表扫描。
- 位图索引：面向取值基数极低（重复度高，如状态标识、类别等）的列。手册中指出它更适用于以只读为主的分析型场景；若在并发频繁写入的 OLTP 场景中使用，容易引发锁竞争，需要审慎评估。
单列索引与复合索引
- 单列与多列组合形式。复合索引同样需要严格遵循最左前缀原则。
虚索引与实索引
- 实索引即正常分配磁盘空间的物理结构；虚索引则属于辅助工具，主要用于在不实际分配物理资源的前提下，协助评估优化器对执行计划的推演。

索引设计与管理准则

管理员手册中强调的管理准则偏向防御性规范，结合以往经验来看，这些考量点在生产运维中确实比较关键：

批量导数时“先导后建”
初始化大批量数据时，先灌入表数据再统一创建索引。这样能减少数据逐条写入时频繁触发的树形节点分裂与维护开销，缩短导数耗时并减少初始碎片。
区分表大小与访问特征
仅包含少量字典数据的小表，全表扫描的成本往往低于“走索引 + 回表”；对高频整表修改的表也应尽量减少索引数量。
复合索引列的顺序安排
高基数列（区分度好、非重复值多）以及高频作为精确过滤条件的列，建议优先排在复合索引的最左侧。
控制单表索引数量
单表的索引数量一般建议控制在合理范围内（通常 5 个左右）。每增加一个索引，写入和更新事务都需要承担额外的同步维护成本。
指定专用表空间
在生产规划中，建议显式为索引指定独立的表空间，与数据表空间在物理层面做一定隔离，有助于分散 I/O 争用。

基础语句演练

在测试库建了一张基础表，根据手册指引进行了几次基础语法演练。

1. 测试表初始化

CREATE TABLE WZL.TEST_USER (
    USER_ID INT PRIMARY KEY,         -- 隐式创建主键聚集/唯一索引
    USER_CODE VARCHAR(30) UNIQUE,    -- 隐式创建唯一索引
    USER_NAME VARCHAR(60),
    DEPT_ID INT,
    STATUS CHAR(1),
    CREATE_TIME DATE
);

2. 常用索引创建语法

DM 支持在创建索引时直接指定专属表空间和存储分配参数：

-- 1. 普通单列索引（指定存放在独立索引表空间 TBS_INDEX）
CREATE INDEX WZL.IDX_USER_DEPT ON WZL.TEST_USER(DEPT_ID) TABLESPACE TBS_INDEX;

-- 2. 复合索引（匹配部门与时间范围的联合查询）
CREATE INDEX WZL.IDX_USER_DEPT_TIME ON WZL.TEST_USER(DEPT_ID, CREATE_TIME) TABLESPACE TBS_INDEX;

-- 3. 基于函数的索引
CREATE INDEX WZL.IDX_USER_NAME_UPPER ON WZL.TEST_USER(UPPER(USER_NAME));

-- 4. 位图索引（适用于低基数状态列）
CREATE BITMAP WZL.INDEX IDX_USER_STATUS ON WZL.TEST_USER(STATUS);

验证与维护管理

1. 执行计划初验

与习惯的执行计划分析类似，DM 可以直接使用 EXPLAIN 查看优化器生成的执行路径：

EXPLAIN SELECT * FROM WZL.TEST_USER WHERE DEPT_ID = 20;

执行计划.png

在执行计划的算子输出中：

CSCN2：表示对聚集结构进行扫描，普通表场景下通常可以理解为全表扫描。
SSEK2：表示通过索引进行范围查找，例如 scan_range[20,30]。
BLKUP2：表示通过索引定位记录后，回到聚集数据区域获取完整数据行。
SLCT2：表示对扫描结果进行条件过滤。

需要注意，不能仅根据算子名称判断索引类型，建议结合执行计划中的索引名称和 DBA_INDEXES.INDEX_TYPE 一起判断。

2. 查看元数据字典

与 PG 系直接查 pg_indexes 或 pg_class 不同，DM 的元数据管理更贴近 Oracle 风格的数据字典视图：

-- 查看指定表的索引状态与基本信息
SELECT INDEX_NAME, INDEX_TYPE, UNIQUENESS, STATUS 
FROM DBA_INDEXES 
WHERE TABLE_NAME = 'TEST_USER';

-- 查看复合索引中字段的排布顺序
SELECT INDEX_NAME, COLUMN_NAME, COLUMN_POSITION 
FROM DBA_IND_COLUMNS 
WHERE TABLE_NAME = 'TEST_USER' 
ORDER BY INDEX_NAME, COLUMN_POSITION;

3. 索引碎片维护与清理

表经过大批量 DELETE 或高频更新后，B 树叶子节点会出现空间闲置与碎片问题。低峰维护期可以执行重建：

-- 常规重建
ALTER INDEX WZL.IDX_USER_DEPT REBUILD;

-- 在线重建（尽可能降低对在线 DML 事务的排他阻塞）
ALTER INDEX WZL.IDX_USER_DEPT REBUILD ONLINE;

-- 删除冗余或无效索引
DROP INDEX WZL.IDX_USER_DEPT;

小结

这次通读手册并进行了几次基础上手操作，初步体会到以下两点：

核心逻辑通畅：无论是索引选择性、复合索引排列次序还是执行计划的验证手段，通用关系型数据库的底层思考逻辑完全可以复用，上手成本比预想的要平缓。
规范细节需留心：DM 在数据字典体系（DBA_* / USER_*）、表空间物理分配以及聚集索引与主键的默认绑定机制上有着自己的规范，在后续实际项目配置时需要多留意这类细节差异。

索引手册规范与初次实操