活动专区

活动公告

上车！GBase 8a开发者联盟发车了 技术福利、人脉资源全都有！

认证培训专区

认证培训资料

GBase 8s GDCA 认证培训课前准备

GBase 8a

其他

物化视图报错：references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them

01-GBase 8s 事务型数据库 安装与卸载

GBase 8s

适配迁移

[GBase 8s 教程]GBase 8s 常用函数、表达式

OLTP 场景里，MySQL/PG 遇到慢查询第一反应是「加个索引」。到了 GBase 8a MPP 环境，事情要复杂一些：GBase 8a 默认按 **分布键做 Hash 分布**，JOIN 与聚合大量依赖数据重分布（Motion），单节点索引用法与单机库有明显差异。建了索引却发现 EXPLAIN 根本不选，也是高频困惑之一。

本文说明 8a 的索引类型、建法、哪些场景真正有用、以及用 EXPLAIN 验证是否生效的思路。

## 一、GBase 8a 的索引类型

GBase 8a 支持两类索引，在集群环境下行为不同：

### 1. 主键与聚集索引（Cluster Key）

建表时声明 `PRIMARY KEY` 或 `CLUSTER KEY`，数据按该键排序存储（类似 MySQL 的聚簇索引）。特点：

- 每个分片内数据按 CLUSTER KEY 物理排序
- 等值查询 `WHERE pk = ?` 可以直接定位分片 + 二分查找，减少扫描范围
- 唯一性由约束保证，不额外存索引结构
- 缺点：写入时维护排序成本高；分布键与 CLUSTER KEY 一致时效果最好

```sql
CREATE TABLE t_orders (
  order_id BIGINT PRIMARY KEY,
  user_id INT,
  amt DECIMAL(18,2),
  dt DATE
) DISTRIBUTED BY ('user_id');
-- order_id 是聚簇键，各分片内按 order_id 排序存储
```

### 2. 二级索引（CREATE INDEX）

```sql
CREATE [UNIQUE] INDEX idx_user ON t_orders(user_id);
CREATE INDEX idx_dt ON t_orders(dt);
-- 支持 HASH、B+TREE（视版本），默认或视存储层而定
```

在 MPP 场景下，二级索引的**可用性判断**比单机库更严：跨分片查询 + 非分布键列上的索引，极可能被忽略（因为扫描成本可能高于全分片扫描）。

### 3. 分区裁剪与索引的配合

分区表上索引更要注意：分区裁剪先于索引生效。若查询带分区键过滤，`dt BETWEEN '2026-01-01' AND '2026-03-31'`，即使 `dt` 列上有索引，也会优先看分区是否被裁剪。

```sql
CREATE TABLE t_log (
  id BIGINT,
  level VARCHAR(16),
  msg TEXT,
  created_at DATE
) PARTITION BY RANGE (created_at) (
  PARTITION p2026q1 VALUES LESS THAN ('2026-04-01'),
  PARTITION p2026q2 VALUES LESS THAN ('2026-07-01'),
  PARTITION p2026q3 VALUES LESS THAN ('2026-10-01'),
  PARTITION p2026q4 VALUES LESS THAN ('2027-01-01')
) DISTRIBUTED BY HASH(id);

-- 查询 dt 在 2026-05，月分区被裁剪时即使 level 列有索引也走分区扫描
SELECT * FROM t_log WHERE created_at = '2026-05-15' AND level = 'ERROR';
```

## 二、哪些场景索引真正有用

| 场景 | 是否有价值建索引 | 原因 |
|------|----------------|------|
| 主键等值查询 | 聚集键已覆盖 | PRIMARY KEY = 聚簇键，无需单独建 |
| 分布键等值查询 | 低价值 | 数据按分布键 Hash，定位分片后全扫 |
| 非分布键等值查询（结果集小） | 可尝试 | 索引可减少扫描行数，需 EXPLAIN 确认 |
| 范围查询（&gt;、BETWEEN） | 通常不选索引 | MPP 全分片扫描更快，索引需逐分片 Seek |
| 分区键过滤 | 分区裁剪优先 | 先看分区是否命中，索引是次要因素 |
| Join 键 | 不要用索引替代 | Join 应靠分布键对齐或 REDISTRIBUTE |
| ORDER BY + LIMIT（小结果集） | 可尝试 | 索引有序可减少排序开销 |
| 唯一性约束 | 必须 UNIQUE INDEX | 保证数据一致性 |

**原则**：GBase 8a MPP 不是 OLTP，索引不是性能优化的第一优先级；先看**分布键设计、分区裁剪、统计信息**，再评估索引。

## 三、索引使用判断：EXPLAIN 验证

建了索引后必须用 EXPLAIN 确认是否生效，否则可能白建。

```sql
-- 先建索引
CREATE INDEX idx_level ON t_log(level);

-- 看执行计划
EXPLAIN
SELECT * FROM t_log WHERE level = 'ERROR' AND created_at = '2026-05-15';

-- 关键看：是否出现 Index Range Scan / Index Seek
-- 若仍出现 Table Scan / 全分区扫描，说明索引未被选中
```

**不选索引的常见原因**

1. **估算行数太大**：优化器认为全表扫描成本更低（检查 `ANALYZE TABLE`）
2. **列上有函数或表达式**：`WHERE DATE(created_at) = '...'` 无法使用 `created_at` 上的索引
3. **多列索引列顺序**：`idx(a, b, c)` 无法支持 `WHERE b = ?`
4. **版本限制**：部分版本对非主键索引支持有限

## 四、案例：ERROR 日志快速定位（索引有效）

**场景**：运维每天查一次 ERROR 级日志，通常 `WHERE level = 'ERROR' AND created_at = ?`，结果集极小（每天几十条）。

**建索引前**

```sql
EXPLAIN
SELECT id, msg, created_at FROM t_log
WHERE level = 'ERROR' AND created_at = '2026-05-20';

-- 计划显示：全分区扫描 + Filter(where level='ERROR')
-- 耗时 8s（扫描整月分区数据）
```

**建索引后**

```sql
CREATE INDEX idx_level_dt ON t_log(level, created_at);

EXPLAIN
SELECT id, msg, created_at FROM t_log
WHERE level = 'ERROR' AND created_at = '2026-05-20';

-- 期望：Index Range Scan / Index Seek on idx_level_dt
-- 耗时降至毫秒级
```

**判断方法**：`EXPLAIN` 输出中找 `idx_level_dt` 相关的 Scan 算子，若仍有 `t_log` 的全分区扫描说明索引未生效。

## 五、案例：索引无效，改用分区裁剪（更有效）

**场景**：历史数据按月分区，每天 `created_at` 查询总是慢。

```sql
CREATE INDEX idx_created_at ON t_log(created_at);

EXPLAIN
SELECT * FROM t_log WHERE created_at BETWEEN '2026-03-01' AND '2026-03-31';
```

**分析**：

- `idx_created_at` 是范围索引，`BETWEEN` 可能触发索引扫描
- 但若分区按月切分，3 月数据占整表 1/12
- 优化器在分片内对比：索引扫描成本 vs 全分区扫描成本
- 结论：分片内数据量足够大时，优化器倾向全分区扫描

**改法**：不要在 `created_at` 上建索引，靠**分区裁剪**控制扫描范围；`BETWEEN` 精确到月/周即可。

```sql
-- 改写查询，让分区裁剪生效
SELECT * FROM t_log
WHERE created_at &gt;= '2026-03-01' AND created_at &lt; '2026-04-01';
-- 配合 EXPLAIN 确认 PartitionPruning 出现
```

## 六、与分布键、统计信息的衔接

```text
[1] 慢查询 → 先看 EXPLAIN 分布键是否对齐、是否有 REDISTRIBUTE
[2] 等值查询返回行少 → 建非分布键索引 + EXPLAIN 验证
[3] 范围查询 → 优先分区裁剪，索引次要
[4] 建索引后 EXPLAIN 仍全表扫描 → 查 ANALYZE、更新统计信息
[5] Join 键不要靠索引 → 靠分布键对齐或 REDISTRIBUTE
```

## 小结

GBase 8a 的索引用法与单机 OLTP 库有明显区别：分布键等值查询靠 Hash 分布定位分片，无需索引；非分布键小结果集等值查询可尝试建索引并用 EXPLAIN 验证是否生效；范围查询和 Join 键场景应优先靠分区裁剪、分布键对齐、统计信息调优，而非堆索引。建索引前先用 `EXPLAIN` 看清当前计划，建后再次 `EXPLAIN` 对比，确认索引被选中再视为有效。团队可在「慢 SQL 处理 SOP」中加一条：等值过滤且结果集小（&lt;总行数 5%）时评估索引，其他场景勿盲目建索引。



GBase 8a 索引设计与 EXPLAIN 验证：从建索引到判断是否用上

评论

热门帖子