1. 执行计划：数据库的"烹饪食谱"

想象一下你要做一道红烧肉，菜谱上写着"准备食材、炖煮、收汁"这几个步骤。数据库执行计划就像这个菜谱，只不过它是告诉数据库如何"烹饪"你的SQL查询。OceanBase作为分布式数据库，它的执行计划生成过程特别有意思——就像一位经验丰富的大厨，会根据食材（数据量）、灶具（服务器资源）和食客要求（查询条件）动态调整烹饪方案。

我第一次接触OceanBase执行计划时，被它的智能程度惊艳到了。当时我写了个简单的多表关联查询，发现OB自动选择了最优的连接顺序，比我手动优化的版本还要快15%。这让我意识到，理解执行计划对开发者来说就像厨师理解火候一样重要。

执行计划本质上是由物理操作符构成的树形结构，OceanBase支持三种基本树形：

• 左深树：像向左倾斜的二叉树，适合大多数JOIN场景
• 右深树：向右倾斜的结构，适合特定类型的嵌套查询
• 多枝树：更复杂的拓扑结构，用于特殊优化场景

-- 查看基本执行计划示例
EXPLAIN BASIC 
SELECT * FROM orders o JOIN customers c ON o.cust_id = c.id 
WHERE c.region = 'EAST';

2. 执行计划深度解析：从菜谱到烹饪实况

2.1 EXPLAIN命令：你的SQL显微镜

EXPLAIN是分析执行计划最常用的工具，就像给SQL做X光检查。OceanBase提供了多种展示格式，我最常用的是EXTENDED模式，它能显示算子详细信息。这里有个实用技巧：在测试环境先用BASIC模式快速查看整体结构，再到预发环境用EXTENDED模式深度分析。

-- 不同详细程度的EXPLAIN示例
EXPLAIN BASIC SELECT * FROM large_table WHERE create_time > '2023-01-01';

EXPLAIN EXTENDED 
SELECT p.* FROM products p 
JOIN inventory i ON p.sku = i.sku 
WHERE i.stock < 10;

执行计划输出包含几个关键部分：

1. 算子树：展示操作符的层级关系
2. 估算信息：包括预估行数(EST.ROWS)和代价(COST)
3. 详细参数：如排序键、过滤条件等

2.2 解读执行计划：像读地铁线路图

理解执行计划的关键是掌握常见算子。我整理了几个核心算子类型：

算子类型	常见算子	作用
表访问	TABLE SCAN, TABLE GET	数据读取
连接	HASH JOIN, NESTED LOOP	表关联操作
排序	SORT, TOP-N SORT	结果排序
分布式	EXCHANGE IN/OUT	节点间数据传输

举个实际案例：有次我发现一个查询突然变慢，通过执行计划发现原本的HASH JOIN变成了NESTED LOOP。检查后发现是统计信息过期导致，更新统计信息后性能立即恢复。这说明执行计划不是一成不变的，优化器会根据数据特征动态调整。

3. 实时执行计划：厨房里的现场直播

3.1 计划缓存：数据库的"肌肉记忆"

OceanBase每个服务器都有独立的计划缓存，就像厨师记住常用菜的做法。通过v$plan_cache_plan_explain可以查看实际使用的物理执行计划，这和EXPLAIN展示的逻辑计划有所不同——前者是实际执行的"现场录像"，后者是优化器的"排练方案"。

-- 查询计划缓存中的执行计划步骤
-- 1. 先找到plan_id
SELECT plan_id FROM v$plan_cache_plan_stat 
WHERE statement LIKE 'SELECT%orders%';

-- 2. 查看具体执行计划
SELECT * FROM v$plan_cache_plan_explain 
WHERE tenant_id = 1001 AND plan_id = 12345;

3.2 逻辑vs物理：剧本与表演的区别

逻辑执行计划使用通用算子名称，而物理执行计划都带有PHY_前缀。比如：

• 逻辑计划：HASH JOIN
• 物理计划：PHY_HASH_JOIN

有次排查性能问题时，我发现逻辑计划显示使用索引，但物理计划却显示全表扫描。原来是索引列数据分布不均匀导致优化器运行时改变了策略。这种差异说明实时执行计划对性能调优至关重要。

4. 高级诊断技巧：成为数据库"老中医"

4.1 SQL Trace：给查询做全身体检

当常规EXPLAIN无法定位问题时，SQL Trace就像核磁共振检查。启用后可以捕获执行过程中的详细时序信息：

-- 启用SQL Trace
SET ob_enable_trace_log = 1;

-- 执行待分析的SQL
SELECT /*+ TRACE */ * FROM large_table WHERE id = 100;

-- 查看Trace结果
SHOW TRACE;

Trace输出会显示每个算子的实际执行时间、内存使用等指标，对定位性能瓶颈特别有用。我曾经用这个方法发现一个隐式的类型转换导致索引失效的问题，优化后查询速度提升了20倍。

4.2 执行计划稳定性管理

OceanBase 4.0引入了SPM(SQL Plan Management)功能，可以锁定最优执行计划，避免计划跳变。这在系统升级或数据量突变时特别有用：

-- 创建SQL计划基线
EXEC DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE(
    sql_id => '8hx12v5yqjg3b',
    plan_hash_value => 123456789
);

-- 验证计划是否固定
SELECT * FROM dba_sql_plan_baselines;

在实际生产环境中，我建议对核心业务SQL配置计划基线，特别是那些对性能敏感的查询。这就像给重要菜品制定标准操作流程，确保每次都能稳定输出。

5. 实战经验：那些年我踩过的坑

执行计划优化是个经验活，分享几个实战中总结的要点：

1. 统计信息要及时更新：过时的统计信息是执行计划出错的首要原因。对大表建议设置自动收集：

   ANALYZE TABLE large_table COMPUTE STATISTICS;
   

2. 注意隐式类型转换：VARCHAR和CHAR混用会导致索引失效，这是我踩过最隐蔽的坑之一

3. 合理使用HINT：当优化器判断不准时，可以用HINT微调：

   SELECT /*+ INDEX(t1 idx_col) */ col1 FROM t1 WHERE col1 = 100;
   

4. 分布式查询要关注数据分布：在OceanBase中，EXCHANGE算子过多通常意味着需要优化分区策略

记得有次处理一个超时查询，原执行计划要走网络传输20GB数据。通过调整JOIN顺序和添加合适的本地索引，最终将数据传输降到了200MB，查询时间从分钟级降到秒级。这种优化带来的成就感，就是技术工作最迷人的地方。