OceanBase执行计划绑定技术：解决SQL性能抖动问题

一、SQL性能抖动：数据库的"心跳不齐"问题

每天处理海量SQL请求的OceanBase数据库，有时会出现一个让人头疼的现象：同一条SQL语句，在不同时间执行时性能差异巨大，就像人的心跳时快时慢。这种性能抖动问题往往源于执行计划的不稳定。

举个真实案例：某电商平台的订单查询接口，在白天高峰期响应时间保持在200ms左右，但到了凌晨却突然飙升到5秒。经过排查发现，OceanBase为同一条SQL生成了两种不同的执行计划：

-- 订单查询SQL示例（OceanBase语法）
SELECT /*+ INDEX(o idx_order_time) */ 
       o.order_id, o.amount, u.user_name
FROM orders o 
JOIN users u ON o.user_id = u.user_id
WHERE o.create_time > '2023-01-01'
  AND o.status = 'PAID'
ORDER BY o.create_time DESC
LIMIT 100;

/* 正常执行计划：使用idx_order_time索引
   -------------------------------------------------------------------
   |ID|OPERATOR           |NAME         |EST.ROWS|COST  |
   -------------------------------------------------------------------
   |0 |LIMIT              |             |100     |274100|
   |1 | TOP-N SORT        |             |100     |274100|
   |2 |  NESTED-LOOP JOIN |             |50000   |273900|
   |3 |   TABLE SCAN      |u            |100000  |66000 |
   |4 |   TABLE SCAN      |o(idx_order) |500     |207900|
   -------------------------------------------------------------------

   异常执行计划：误用全表扫描
   -------------------------------------------------------------------
   |ID|OPERATOR           |NAME         |EST.ROWS|COST  |
   -------------------------------------------------------------------
   |0 |LIMIT              |             |100     |587460|
   |1 | TOP-N SORT        |             |100     |587460|
   |2 |  NESTED-LOOP JOIN |             |1000000 |586960|
   |3 |   TABLE SCAN      |u            |100000  |66000 |
   |4 |   TABLE SCAN      |o(PRIMARY)   |10000000|520960|
   -------------------------------------------------------------------
*/

二、执行计划绑定的工作原理

OceanBase的执行计划绑定（Plan Baseline）技术就像给SQL语句配了个私人教练，它会记住经过验证的最佳执行方案。其核心流程分为三个阶段：

1. 捕获阶段：系统自动收集SQL的执行计划，形成候选集合
2. 验证阶段：评估各个执行计划的性能指标
3. 固定阶段：将最优计划标记为"已接受"状态

具体实现时，可以通过以下命令创建绑定：

-- 创建SQL绑定（OceanBase 3.x语法）
CREATE OUTLINE ln_order_query 
ON 'SELECT /*+ INDEX(o idx_order_time) */ 
       o.order_id, o.amount, u.user_name...'
USING HINT 'INDEX(o idx_order_time)';

-- 查看绑定状态
SELECT * FROM __all_virtual_outline WHERE outline_name = 'ln_order_query';

/* 输出示例：
   +--------------+---------------------+-----------------------------+
   | outline_name | create_time         | outline_content             |
   +--------------+---------------------+-----------------------------+
   | ln_order_query| 2023-06-18 10:00:00 | INDEX(o idx_order_time)     |
   +--------------+---------------------+-----------------------------+
*/

三、实战：从抖动到稳定的全过程

让我们通过一个完整的电商场景示例，演示如何解决分页查询的性能抖动问题。

3.1 问题重现

某商品列表页SQL在数据量变化时出现计划切换：

-- 商品分页查询（参数化SQL）
SELECT * FROM products 
WHERE category_id = ? 
  AND is_online = 1
ORDER BY sales_volume DESC
LIMIT ?, ?;

/* 当category_id=1（数据量少）时使用索引扫描：
   -------------------------------------------------
   |ID|OPERATOR       |NAME          |COST     |
   -------------------------------------------------
   |0 |LIMIT          |              |200      |
   |1 | TABLE SCAN    |products(idx_category)|200|
   -------------------------------------------------

   当category_id=2（数据量大）时误用全表扫描：
   -------------------------------------------------
   |ID|OPERATOR       |NAME          |COST     |
   -------------------------------------------------
   |0 |LIMIT          |              |50000    |
   |1 | MERGE SORT    |              |50000    |
   |2 |  TABLE SCAN   |products(PRIMARY)|45000 |
   -------------------------------------------------
*/

3.2 解决方案实施

分三步建立执行计划绑定：

-- 步骤1：捕获当前最佳计划（使用FORCE INDEX）
EXPLAIN 
SELECT /*+ INDEX(products idx_category_sales) */ * 
FROM products FORCE INDEX(idx_category_sales)
WHERE category_id = 2
  AND is_online = 1
ORDER BY sales_volume DESC
LIMIT 0, 50;

-- 步骤2：创建绑定大纲
CREATE OUTLINE ln_product_list 
ON 'SELECT * FROM products WHERE category_id=? AND is_online=1...'
USING HINT 'INDEX(products idx_category_sales)';

-- 步骤3：验证绑定效果
SET ob_enable_outline = TRUE;
EXPLAIN 
SELECT * FROM products 
WHERE category_id = 2
  AND is_online = 1
ORDER BY sales_volume DESC
LIMIT 0, 50;

/* 验证输出：确认使用指定索引
   ------------------------------------------------------
   |ID|OPERATOR       |NAME                 |COST     |
   ------------------------------------------------------
   |0 |LIMIT          |                     |300      |
   |1 | TABLE SCAN    |products(idx_category_sales)|300|
   ------------------------------------------------------
*/

四、技术深潜：绑定机制的内部原理

OceanBase的执行计划绑定底层采用"指纹+版本"的双重校验机制：

1. SQL指纹：通过64位哈希值唯一标识SQL语句
2. 版本兼容：每个绑定关联特定的数据库版本号
3. 多计划缓存：一个SQL可以保留多个已验证的执行计划

通过系统视图可以查看内部状态：

-- 查看执行计划缓存（需要DBA权限）
SELECT /*+ READ_CONSISTENCY(WEAK) */ 
       sql_id, plan_id, executions, elapsed_time
FROM gv$plan_cache_plan_stat
ORDER BY elapsed_time DESC
LIMIT 5;

/* 典型输出：
   +------------------+---------+------------+-------------+
   | sql_id           | plan_id | executions | elapsed_time|
   +------------------+---------+------------+-------------+
   | 7F3A5C2E1B8D9...| 28341   | 15020      | 3250.27     |
   | A4B6C8D0E2F1... | 15382   | 8021       | 1820.56     |
   +------------------+---------+------------+-------------+
*/

-- 查看绑定关系映射
SELECT sql_id, outline_id 
FROM __all_virtual_sql_audit
WHERE outline_id > 0;

/* 输出示例：
   +------------------+------------+
   | sql_id           | outline_id |
   +------------------+------------+
   | 7F3A5C2E1B8D9...| 1024       |
   +------------------+------------+
*/

五、应用场景与最佳实践

5.1 最适合的使用场景

• 参数化查询在数据分布不均时性能差异大
• 关键业务SQL需要稳定响应时间
• 升级迁移时需要保持执行计划稳定

5.2 实际效果对比

某金融系统实施绑定前后的性能对比：

5.3 使用注意事项

1. 版本兼容性：不同OceanBase版本间的绑定可能需要重建
2. 统计信息更新：建议在统计信息更新后重新评估绑定
3. 内存消耗：每个绑定约占用5-10KB内存
4. 绑定优先级：手动绑定 > 自动捕获 > 优化器选择

-- 推荐的绑定维护流程
-- 1. 定期检查失效绑定
SELECT outline_name, schema_version 
FROM __all_virtual_outline 
WHERE schema_version < CURRENT_SCHEMA_VERSION();

-- 2. 清理过期绑定（谨慎操作！）
DROP OUTLINE ln_old_binding;

六、技术对比：与其他方案的优劣

与传统hint固定方式相比，执行计划绑定的优势在于：

但也要注意其局限性：

• 不适用于高度动态的SQL模式
• 对DDL操作敏感（如索引变更）
• 需要额外的监控维护

七、总结与展望

执行计划绑定就像给SQL语句安装了"自动驾驶"系统，既能保持路线稳定，又允许在必要时人工接管。这项技术在OceanBase中的实现展现了分布式数据库在智能化演进中的重要一步。

未来发展方向可能包括：

1. 基于机器学习的自适应绑定
2. 跨集群的绑定同步机制
3. 细粒度的绑定版本管理

通过合理使用执行计划绑定，我们终于可以让数据库的"心跳"保持平稳，为业务系统提供更可靠的基础保障。