GBase 8a 执行计划跑偏怎么办？从统计信息到 Hint 的完整调优指南

一、问题背景：执行计划为什么会"跑偏"？

在 GBase 8a 的日常运维中，你可能遇到过这样的情况：

• 同一条 SQL，昨天跑 3 秒，今天跑 3 分钟；
• 明明建了索引，EXPLAIN 看到的却是全表扫描（type = ALL）；
• 大表 JOIN 小表，优化器偏偏选了错误的驱动顺序。

这类问题，根源往往不在 SQL 本身，而在于统计信息过期或缺失，导致查询优化器基于错误的成本估算，选出了低效的执行计划。

二、统计信息基础：Cardinality 是什么？

GBase 8a 的查询优化器是**基于代价（Cost-Based）**的优化器，它在生成执行计划时，依赖对每张表/列的统计信息来估算：

• 表中有多少行（行数）
• 某列有多少个不同值（Cardinality，基数）
• 数据分布是否均匀（直方图）

Cardinality（基数） 是其中最核心的指标之一。它代表某一列去重后的唯一值数量。

示例：

-- 查看某列的统计信息
SHOW INDEX FROM orders;

-- 或通过 information_schema 查询
SELECT TABLE_NAME, COLUMN_NAME, CARDINALITY
FROM information_schema.STATISTICS
WHERE TABLE_SCHEMA = 'your_db' AND TABLE_NAME = 'orders';

如果 Cardinality 长期未更新，与实际数据严重不符，优化器的决策就会出错。

三、ANALYZE TABLE：统计信息的刷新利器

3.1 基本用法

-- 分析单表
ANALYZE TABLE orders;

-- 分析多张表
ANALYZE TABLE orders, order_items, customers;

3.2 执行后统计信息什么时候生效？

ANALYZE TABLE 执行完成后，统计信息立即更新到数据字典中，后续新生成的查询计划会使用新统计信息。

⚠️ 注意：正在执行的查询不受影响，它们仍使用执行开始时已生成的执行计划，不会中途切换。

3.3 新增分区后为什么必须执行 ANALYZE？

GBase 8a 是分布式 MPP 数据库，分区是数据组织的核心单元。当你新增一个分区后：

1. 新分区的数据尚未纳入统计信息；
2. 优化器看到的行数估算可能严重偏低；
3. 跨节点 JOIN 时，数据倾斜的判断会失准；
4. 最终导致执行计划选错 JOIN 方式或 Hash 分桶策略。

不执行 ANALYZE 的后果：

• 优化器低估新分区数据量，可能跳过应该使用的分区裁剪；
• 聚合操作选择错误的并行度；
• 全集群性能下降，且问题排查困难。

最佳实践：

-- 新增分区后立即执行
ALTER TABLE sales ADD PARTITION (PARTITION p202406 VALUES LESS THAN ('2024-07-01'));

-- 紧跟着执行 ANALYZE
ANALYZE TABLE sales;

四、EXPLAIN 诊断：看懂执行计划的关键字段

4.1 type = ALL 意味着什么？

EXPLAIN SELECT * FROM orders WHERE customer_id = 12345;

输出中如果出现 type: ALL，代表全表扫描：优化器扫描了表中所有行来找到目标数据。

常见原因：

解决步骤：

-- 第一步：确认索引存在
SHOW INDEX FROM orders;

-- 第二步：更新统计信息
ANALYZE TABLE orders;

-- 第三步：再次 EXPLAIN 查看是否改善
EXPLAIN SELECT * FROM orders WHERE customer_id = 12345;

-- 如果仍然是全表扫描，检查 SQL 写法
-- 避免：WHERE CAST(customer_id AS CHAR) = '12345'
-- 改为：WHERE customer_id = 12345

五、Hint：当优化器"拿不定主意"时的干预手段

统计信息正确，但优化器仍然选出了糟糕的执行计划？这时可以使用 Hint 强制指定执行策略。

5.1 什么情况下需要用 Hint？

• 数据分布极度不均匀，优化器估算不准；
• 特定业务查询对执行顺序有明确要求；
• 升级版本后执行计划发生退化；
• 临时紧急处理线上慢 SQL，来不及改表结构。

⚠️ Hint 是"临时药"，不是"根治药"。长期依赖 Hint 说明需要从索引设计或统计信息维护上根本解决。

5.2 GBase 8a 常用 Hint 类型

（1）JOIN 顺序 Hint

-- STRAIGHT_JOIN：强制按 FROM 子句中的表顺序进行 JOIN
SELECT STRAIGHT_JOIN a.*, b.name
FROM large_table a
JOIN small_table b ON a.id = b.id;

（2）索引 Hint

-- USE INDEX：建议优化器使用指定索引
SELECT * FROM orders USE INDEX (idx_customer_id)
WHERE customer_id = 12345;

-- FORCE INDEX：强制使用指定索引（比 USE INDEX 更强）
SELECT * FROM orders FORCE INDEX (idx_customer_id)
WHERE customer_id = 12345;

-- IGNORE INDEX：忽略某个索引
SELECT * FROM orders IGNORE INDEX (idx_create_time)
WHERE customer_id = 12345;

（3）并行度 Hint（GBase 8a 特有）

GBase 8a 支持通过 /*+ ... */ 注释风格的 Hint 控制并行执行：

-- 指定查询并行度
SELECT /*+ PARALLEL(4) */ COUNT(*) FROM large_table;

5.3 Hint 使用注意事项

1. Hint 不会报错，即便写错了也会被静默忽略，建议加 EXPLAIN 验证是否生效；
2. 跨版本升级后 Hint 的行为可能有变化，需重新验证；
3. 应在注释中记录为什么加了这个 Hint，便于后续维护。

六、完整调优流程图

发现慢 SQL
    │
    ▼
EXPLAIN 分析执行计划
    │
    ├─► type=ALL / 未走索引？
    │       │
    │       ├─► 检查索引是否存在 → 无则建索引
    │       └─► 索引存在但未使用 → ANALYZE TABLE → 再次验证
    │
    ├─► JOIN 顺序异常？
    │       └─► 更新统计信息 → 仍异常则考虑 STRAIGHT_JOIN Hint
    │
    └─► 统计信息正常，计划仍低效？
            └─► 使用 Hint 干预 + 记录原因 + 纳入定期复查

七、运维建议：统计信息的日常管理

八、总结

GBase 8a 执行计划"跑偏"，90% 的根因是统计信息问题。养成以下习惯，可以避免大多数性能陷阱：

1. 变更数据后 ANALYZE：加载数据、新增分区后立即执行；
2. EXPLAIN 先行：优化前先看执行计划，找到真正的瓶颈；
3. Hint 是辅助：优先通过统计信息和索引解决，Hint 作为应急手段；
4. 定期复查：业务数据量变化会让旧的统计信息失效，定期维护是关键。