达梦数据库索引实战：从原理到优化，解决性能与空间难题

1. 从一次“空间不足”的报错说起：索引为何如此重要？

最近在维护一个基于达梦数据库的系统时，遇到了一个典型的性能瓶颈。一个核心的出货明细表c##hf_hshun_yd.pk_sd_shipment_dtl在执行高频查询时变得异常缓慢，更棘手的是，偶尔会抛出“无法通过 128 (在表空间 users 中) 扩展”的错误。这个错误直接指向了表空间的空间耗尽问题。初步排查，数据量增长固然是原因之一，但深究下去，发现根源在于索引的缺失与滥用。没有合适的索引，数据库引擎被迫进行全表扫描，不仅拖慢了查询，大量临时排序和哈希操作也在疯狂消耗表空间的临时段，最终触发了空间警报。

这个案例让我再次深刻体会到，在达梦（DM）数据库乃至任何关系型数据库中，表索引绝不是可有可无的装饰品，而是直接影响系统性能、稳定性和可扩展性的核心组件。它就像一本书的目录，没有目录，你要找某一页的内容，只能一页一页地翻（全表扫描）；有了精准的目录（有效索引），你就能直达目标。然而，索引的创建和管理又是一门学问，建得不好，反而会成为“负担”，影响数据写入速度，并占用额外的存储空间。

无论是你正在从 Oracle、MySQL 迁移至达梦，还是在全新的达梦数据库上进行课程设计、开发应用，理解并善用索引都是绕不开的课题。网络上关于“达梦数据库使用教程”、“navicat连接达梦数据库步骤”的教程很多，但往往停留在基础操作。本文将从一个实际运维和开发的角度，深入探讨达梦数据库表索引的核心原理、创建策略、管理维护以及那些教程里不会写的“避坑指南”。我们会涵盖从基础概念到进阶优化，并结合“达梦awr报告”分析、空间问题排查等实战场景，让你不仅能创建索引，更能创建“对”的索引。

2. 达梦索引的核心机制：与Oracle的异同及内部探秘

在深入实操之前，有必要理解达梦数据库索引的底层逻辑。达梦数据库在设计上兼容Oracle，因此在索引的许多基础概念和实现机制上与Oracle非常相似，这为从Oracle迁移过来的开发者降低了学习成本。但知其然，也要知其所以然。

2.1 索引的物理结构：B+树的主导地位

达梦数据库默认的索引类型是B+树索引，这也是最常用、最高效的用于范围查询和等值查询的索引结构。你可以把它想象成一棵倒置的树：

• 根节点与分支节点：存储了索引键的值范围以及指向下一层节点的指针。
• 叶子节点：这是B+树的核心。它不仅仅存储了索引键的值，还直接包含了指向表中对应数据行（ROWID）的指针。在达梦中，叶子节点之间还通过双向链表连接，这使得基于索引的范围扫描（如BETWEEN,>，<）异常高效，因为引擎可以沿着链表顺序读取，而无需回溯到树的根部。

当你执行一条如SELECT * FROM orders WHERE order_id = 12345的查询时，如果order_id上有索引，数据库会：

1. 从索引的根节点开始，根据键值12345逐层向下查找。
2. 快速定位到包含12345的叶子节点。
3. 从该叶子节点中获取对应的ROWID。
4. 使用这个ROWID直接到表中（也称为“回表”）取出该行的所有数据。

这个过程避免了扫描整张orders表，尤其是当表有上千万行时，性能差异是天壤之别。

2.2 达梦的特色索引类型与应用场景

除了标准的B+树索引，达梦还支持其他几种索引类型，用于特定场景：

• 位图索引：适用于低基数列，即列中唯一值数量很少的列，例如“性别”、“状态（启用/禁用）”、“省份”等。位图索引使用位图（0和1的序列）来表示数据，在复杂条件查询（多列AND/OR）时，可以通过高效的位运算快速定位数据，非常适合数据仓库和OLAP场景下的分析查询。但请注意，位图索引不适合高并发的OLTP场景，因为其对数据更新的开销较大。
• 函数索引：基于表达式或函数创建的索引。例如，你经常需要按UPPER(customer_name)进行查询，那么直接对customer_name列创建索引是无效的。此时可以创建函数索引CREATE INDEX idx_upper_name ON customers(UPPER(customer_name));。这样，查询条件中使用WHERE UPPER(customer_name) = ‘ALICE’时就能利用该索引。
• 全文索引：用于对文本内容（如CLOB或VARCHAR大字段）进行关键词搜索。这不同于LIKE ‘%keyword%’的模糊匹配（这种写法无法使用普通索引），全文索引通过分词和倒排索引技术，可以实现高效的语义搜索，是处理文档、文章类数据的利器。
• 唯一索引 vs 非唯一索引：唯一索引保证索引键值的唯一性（如主键），非唯一索引则允许重复。达梦会自动为主键和唯一约束创建唯一索引。

2.3 与Oracle的兼容性与细微差异

对于Oracle开发者来说，大部分索引的SQL语法（CREATE INDEX,DROP INDEX,ALTER INDEX ... REBUILD）在达梦中是直接兼容的。这包括在线重建索引、监控索引使用情况等高级操作。然而，在一些内部实现和特性上可能存在细微差别，例如某些内部视图的名称（如达梦的DBA_INDEXES、USER_IND_COLUMNS与Oracle类似但前缀可能不同）、存储参数的具体表现等。在进行“数据库迁移”（如从Oracle到DM）时，索引结构通常可以平滑迁移，但迁移后的性能验证和索引重建是必不可少的步骤。

3. 索引的创建策略：如何设计高效的索引？

知道了索引是什么，接下来就是最关键的一步：怎么建？盲目创建索引是DBA和开发者的常见误区，会导致“索引泛滥”，反而降低性能。

3.1 索引创建的基本原则

1. 为查询的WHERE子句服务：这是最根本的原则。索引应建在经常出现在WHERE、JOIN ... ON、ORDER BY、GROUP BY子句中的列上。分析你的核心SQL语句（可以通过达梦AWR报告或动态性能视图获取），找出最频繁、最消耗资源的过滤条件。
2. 高选择性原则：索引列的选择性越高，索引过滤掉的数据就越多，效率就越高。例如，“身份证号”列的选择性远高于“性别”列。对于低选择性列，除非与其他列组成复合索引，否则单独创建索引收益甚微。
3. 考虑复合索引的列顺序：复合索引（多列索引）中列的顺序至关重要。应遵循“最左前缀匹配原则”。假设创建了索引idx_a_b_c (column_a, column_b, column_c)，那么以下查询能利用该索引：
   • WHERE column_a = ?
   • WHERE column_a = ? AND column_b = ?
   • WHERE column_a = ? AND column_b = ? AND column_c = ?但WHERE column_b = ?或WHERE column_c = ?则无法利用这个索引。因此，应将最常用、选择性最高的列放在复合索引的最左边。
4. 避免在频繁更新的列上建过多索引：索引虽然加速读，但会拖慢写（INSERT、UPDATE、DELETE），因为数据变更时需要同步维护所有相关的索引结构。对于写入极其频繁的表，需要谨慎评估索引数量。

3.2 实战：使用SQL和图形工具创建索引

使用SQL命令创建： 这是最灵活和可脚本化的方式。

-- 创建普通非唯一索引 CREATE INDEX idx_shipment_order_id ON c##hf_hshun_yd.sd_shipment_dtl(order_id); -- 创建唯一索引 CREATE UNIQUE INDEX uk_user_email ON users(email); -- 创建复合索引 CREATE INDEX idx_order_date_status ON orders(order_date DESC, status); -- 创建函数索引 CREATE INDEX idx_upper_product_name ON products(UPPER(product_name)); -- 指定表空间创建（管理存储位置） CREATE INDEX idx_large_table ON large_table(column1) STORAGE(ON INDEX_TS);

使用图形化管理工具： 对于不熟悉命令的开发者，达梦数据库管理工具（DM Manager）或第三方工具如Navicat（需安装达梦插件）提供了直观的界面。以Navicat为例，连接达梦数据库后，在目标表上右键“设计表”，找到“索引”选项卡，即可通过图形界面添加、删除索引，设置索引类型和列顺序。这种方式优点是直观，适合简单操作和快速原型设计。

3.3 从网络热词看常见场景的索引设计

• sql server创建表同时创建索引：在达梦中，你可以在CREATE TABLE语句中直接定义主键或唯一约束，这会自动创建索引。对于非唯一索引，通常建议在表创建后，根据实际业务查询模式再创建，因为初期业务模式可能不明确。

  CREATE TABLE employees ( emp_id INT PRIMARY KEY, -- 自动创建唯一索引 emp_name VARCHAR(100), dept_id INT, hire_date DATE, CONSTRAINT uk_emp_email UNIQUE (email) -- 自动创建唯一索引 ); -- 后续根据查询需要再创建 CREATE INDEX idx_emp_dept_hiredate ON employees(dept_id, hire_date);

• mysql varchar 迁移到 达梦varchar/datax的mysql迁移达梦：在数据迁移过程中，索引不会自动迁移。你需要使用DataX等工具迁移完表数据后，在达梦侧重新分析查询语句，并重新创建索引。直接照搬MySQL的索引策略可能不是最优的，因为两个数据库的优化器、统计信息收集机制有差异。迁移后，务必对核心查询进行性能测试。

• 数据库并发锁：不合理的索引是导致锁竞争和阻塞的重要原因之一。例如，当UPDATE语句的WHERE条件无法使用索引时，会导致锁升级（行锁升级为表锁），极大影响并发性。确保高频更新的事务都能通过索引快速定位到目标行，是减少锁冲突的关键。

4. 索引的维护、监控与问题排查

索引不是创建完就一劳永逸的。随着数据的增删改，索引会变得“碎片化”，导致性能下降。同时，你也需要监控哪些索引真正被用到了，哪些是“僵尸索引”。

4.1 索引重建与碎片整理

B+树索引在多次更新后，叶子节点可能不再物理连续，逻辑顺序也存在空洞，这会增加磁盘I/O，降低范围扫描效率。达梦提供了在线重建索引的功能，对业务影响较小：

-- 重建单个索引 ALTER INDEX idx_shipment_order_id REBUILD; -- 重建某个表的所有索引 ALTER TABLE c##hf_hshun_yd.sd_shipment_dtl REBUILD INDEX ALL;

何时重建？可以通过查询达梦的系统视图，估算索引的碎片化程度。一个简单的经验法则是，对于频繁更新的核心表，可以定期（如每周或每月）在业务低峰期执行重建操作。

4.2 利用达梦AWR报告分析索引效能

达梦的AWR（自动工作负载仓库）报告是性能分析的利器。在报告中的“SQL详细统计信息”部分，你可以找到：

1. 执行计划：查看SQL是否使用了你期望的索引。如果出现了FULL SCAN（全表扫描），就需要考虑是否缺失索引或索引失效。
2. 等待事件：如果大量等待事件与“db file sequential read”（索引扫描）或“db file scattered read”（全表扫描）相关，能侧面反映索引使用情况。
3. 开销最高的SQL：针对这些SQL，重点分析其执行计划，优化其索引。

生成AWR报告通常需要使用达梦的管理工具或命令行，报告会清晰指出哪些SQL是“瓶颈”，并给出索引建议（在某些版本中）。

4.3 识别并删除无用索引

“僵尸索引”不仅占用空间（还记得开头的表空间不足问题吗？），还会降低DML操作速度。如何识别？

1. 查询从未被使用过的索引：达梦数据库的系统视图SYS.”V$OBJECT_USAGE”（或类似视图，具体名称请参考对应版本手册）可以跟踪索引的使用情况。你需要先开启索引监控。

   ALTER INDEX idx_shipment_order_id MONITORING USAGE; -- 运行一段时间的业务负载后 SELECT * FROM V$OBJECT_USAGE WHERE INDEX_NAME = ‘IDX_SHIPMENT_ORDER_ID’; -- 如果 USED 列为 ‘NO’，则考虑删除 DROP INDEX idx_shipment_order_id;

2. 分析索引与查询的匹配度：有时索引被使用了，但效率不高（如返回数据量过大，优化器可能仍选择全表扫描）。这需要结合AWR报告和SQL执行计划进行深度分析。

4.4 解决“空间不足”与索引存储管理

开头的错误“无法通过 128 (在表空间 users 中) 扩展”，除了数据增长，索引的过度膨胀和碎片化也是元凶。你需要：

1. 检查索引所在表空间：确认索引是否与表数据存储在同一个表空间（如USERS）。对于大型系统，建议将索引存放在独立的表空间（如INDEX_TS），便于单独管理和备份。
2. 评估索引大小：查询数据字典，了解每个索引占用的空间。

   SELECT SEGMENT_NAME, BYTES/1024/1024 AS SIZE_MB FROM DBA_SEGMENTS WHERE SEGMENT_TYPE = ‘INDEX’ AND TABLESPACE_NAME = ‘USERS’ ORDER BY BYTES DESC;

3. 制定存储策略：为索引表空间设置合理的自动扩展属性，但也要设置上限，避免单个索引或表空间无限膨胀拖垮整个存储。定期清理无用索引和重建碎片化索引，是释放空间、提升性能的有效手段。

5. 高级主题与疑难杂症处理

掌握了基础，我们来看一些更复杂的情况和常见坑点。

5.1 索引失效的常见场景

即使创建了索引，在某些情况下优化器也不会使用它，导致索引“失效”：

1. 对索引列进行函数或运算操作：WHERE UPPER(name) = ‘TOM’（除非有函数索引），WHERE salary * 12 > 100000。应该重写为WHERE name = UPPER(‘tom’)或WHERE salary > 100000/12。
2. 使用LIKE ‘%xxx%’前导通配符：WHERE name LIKE ‘%son’无法使用name列的索引。考虑使用全文索引，或如果业务允许，使用LIKE ‘son%’。
3. 隐式类型转换：如果索引列是VARCHAR类型，而查询条件是WHERE id = 123（数字），数据库可能会对列进行隐式转换，导致索引失效。应确保类型一致：WHERE id = ‘123’。
4. 优化器认为全表扫描更快：当表中数据量很小，或者查询需要返回超过总行数一定比例（例如，达梦优化器内部的一个阈值，通常是15%-30%）的数据时，优化器可能认为顺序读全表比随机读索引再回表的成本更低。此时，即使有索引，也可能被忽略。

5.2 分区表上的索引策略

对于海量数据表，达梦支持分区技术（范围、列表、哈希分区等）。分区表上的索引分为两类：

• 全局索引：跨越所有分区的单个索引。维护成本高，分区维护操作（如DROP PARTITION）可能导致全局索引失效（需要UPDATE GLOBAL INDEXES或重建）。
• 本地索引：每个分区都有一个独立的索引分区，与数据分区一一对应。管理方便，分区维护操作不影响其他分区索引的可用性，是更常用的选择。 选择哪种，取决于你的查询模式。如果查询条件总能包含分区键，本地索引效率很高。如果查询经常不包含分区键，则可能需要全局索引。

5.3 迁移与异构环境下的索引考量

在“windows服务器怎么讲oracle数据库表结构及表数据迁移到mysql上”或迁移到达梦的场景中，索引迁移是个挑战：

1. 语法兼容：使用迁移工具（如DataX、DTS）或手动导出DDL时，注意索引定义语法的差异。例如，某些数据库的索引选项（如INVISIBLE索引、压缩方式）可能不被目标数据库支持。
2. 性能验证：迁移后，绝不能假设源库的索引在目标库上依然最优。必须在目标库（达梦）上重新收集统计信息，并运行典型的业务查询进行性能测试，根据达梦的执行计划调整索引策略。
3. 空间规划：不同数据库的索引存储效率和内部结构不同，迁移后索引占用的空间可能与源库有差异，需要提前规划好表空间大小。

索引是数据库性能调优中性价比最高的手段之一，但也是一把双刃剑。它需要基于对业务数据的深刻理解和对查询模式的持续分析来设计和维护。从开头的空间报警，到中间的创建策略，再到后期的维护监控，每一个环节都离不开“合适”二字。没有放之四海而皆准的索引模板，最好的索引永远是那个最能解决你当前系统核心查询痛点的索引。下次当你面对慢查询时，不妨先从索引的角度入手，或许就能找到那条通往性能提升的捷径。