当前位置：首页 > news >正文

达梦sql索引不生效

news 2026/5/12 3:32:05

常见场景：

刚导入了大量数据（比如从别的库迁移过来）；
对某张表做了大量 DELETE / INSERT，行数变化非常大；
新建了索引，特别是影响关键查询的索引；
某些业务查询突然变慢，而且怀疑是执行计划变了；
升级数据库版本、调整某些优化器参数之后。

解决办法

遇到这种问题，通常是数据库优化器不生效，在mysql中优化器会自动处理数据的信息，但是达梦数据库需要收到收集数据统计信息，语法如下：

BEGINDBMS_STATS.GATHER_TABLE_STATS(ownname => 'schema_name',     -- 表所属用户tabname => 'tbal_name', -- 表名cascade => TRUE          -- 同时也收集索引的统计信息);
END;
-- 或者下面的写法也可以
CALL DBMS_STATS.GATHER_TABLE_STATS('schema_name', 'tbal_name', cascade=>TRUE);

统计信息说明

统计信息具体包含哪些内容

收集统计信息时，达梦主要会记录这些“数字”：

表级信息（整张表的概况）
- 表的总行数（NUM_ROWS）
- 表占用的块数 / 页数
- 平均行长度（AVG_ROW_LEN）
  这些信息让优化器知道：这张表是“小表”还是“大表”，适合全表扫描还是索引访问。
列级信息（每列的分布情况）
- 列的不同值个数（distinct 值数量 / 基数）
- 最小值、最大值
- 是否有 NULL、NULL 的数量
- 更重要的是：直方图（Histogram）
  直方图就是把这个列的值按区间分桶，统计每个桶里有多少行，比如：
- PLACE_CODE = ‘340000000000’ 这类值占了全表的 10% 还是 80%？
- CREATE_TIME 在某个时间范围内有多少条记录？
  这些信息直接影响优化器对“过滤条件”的估算。
索引级信息（每个索引的概况）
- 索引的高度（B+树的深度）
- 索引叶子块的个数
- 聚簇因子（Clustering Factor，反映索引顺序和表数据物理顺序的吻合程度）
  这些信息让优化器知道：通过这个索引查找，大概要读多少块，是不是比全表扫描更划算。

作用

帮助判断“走索引”还是“全表扫描”。比如：

表有 100 万行
WHERE 条件：某个值只占 1 万行（1%）
统计信息告诉优化器：“这个条件过滤掉 99% 的数据，很适合走索引。”
于是 CBO（基于代价的优化器）选择“索引范围扫描 + 少量回表”。如果统计信息不准（比如根本没收集，统计信息里还是“只有 100 行”的旧数据），优化器可能误以为这个表很小，直接全表扫描，结果扫了 100 万行，变得非常慢。

帮助决定“关联顺序”和“关联方式”。多表关联时，优化器要算：

哪张表作为“驱动表”（先查的那张）
用 Nested Loop（嵌套循环）还是 Hash Join 还是 Merge Join
比如：
- 表 A 只有 100 行
- 表 B 有 1000 万行
- A 和 B 通过某个字段关联
  统计信息会告诉优化器：A 很小，B 很大，那就应该用 A 当驱动表，对 B 走索引或做 Hash Join。如果没有统计信息，优化器可能错误地让 1000 万行的表当驱动表，然后对 100 行的小表反复访问，结果极慢。

帮助估算“过滤后的行数”，决定是否用某些高级特性。

例如：你的查询里有 WHERE PLACE_CODE like '340000000000%' AND CREATE_TIME BETWEEN ...
优化器需要知道：
- ‘340000000000’ 这种前缀大概占多少比例？
- 这个时间区间大概有多少行？
只有通过“列统计信息 + 直方图”，它才能相对准确地估算“过滤后的行数”，进而判断：
- 用（PLACE_CODE, CREATE_TIME）索引更合适
- 还是只用 CREATE_TIME 索引更合适
- 甚至根本不用索引，直接全表扫描更快
我们这条 3 秒的 SQL，就是优化器在没有准确统计信息的情况下，误判了行数和分布，错误地走了“先按时间扫、再回表过滤地区”的低效路径。