TiDB执行计划：解读分布式查询计划

TiDB执行计划：解读分布式查询计划

【免费下载链接】tidb TiDB 是一个分布式关系型数据库，兼容 MySQL 协议。* 提供水平扩展能力；支持高并发、高可用、在线 DDL 等特性。* 特点：分布式架构设计；支持 MySQL 生态；支持 SQL 和 JSON 数据类型。 项目地址: https://gitcode.com/GitHub_Trending/ti/tidb

引言：分布式数据库的查询优化挑战

你是否曾在分布式环境中遇到SQL查询性能瓶颈？当数据分散在多个节点，传统单机数据库的查询优化策略已不再适用。TiDB作为分布式关系型数据库（Distributed Relational Database），其执行计划（Execution Plan）不仅需要考虑单机上的操作效率，还要处理数据分布、网络传输和节点协同等复杂问题。本文将深入解析TiDB执行计划的构建过程、分布式特性及优化技巧，帮助你掌握分布式查询性能调优的核心方法。

读完本文后，你将能够：

• 理解TiDB执行计划的生成流程与Cascades优化框架
• 掌握EXPLAIN语句的使用方法及输出解读
• 识别分布式查询中的常见性能瓶颈
• 应用执行计划优化技巧提升分布式查询性能

TiDB查询优化器架构：Cascades模型的实践

TiDB采用基于Cascades优化框架的新一代查询优化器，相比传统优化器具有更强大的计划搜索能力和成本模型。其核心架构包含逻辑优化（Logical Optimization）和物理优化（Physical Optimization）两个阶段，通过等价表达式变换和成本计算选择最优执行计划。

优化器工作流程

逻辑优化：等价表达式变换

逻辑优化阶段通过一系列转换规则（Transformation Rules）对逻辑计划进行等价变换，扩展搜索空间。关键优化技术包括：

• 谓词下推（Predicate Pushdown）：将过滤条件尽可能下移至存储层执行，减少数据传输量
• 连接重排序（Join Reorder）：采用动态规划（DP-SUB）算法寻找最优表连接顺序，核心代码如下：

func dp(int nodeCnt) {
    for i := 0; i < nodeCnt; i++ {
        bestPlan[1 << i] = planByNodeID[i]
        bestCost[1 << i] = 0
    }
    for state := 1; state < (1 << nodeCnt); state++ {
        if bits.OnesCount(i) == 1 || (nodeCnt not connected) {
            continue
        }
        for sub := (state - 1) & state； sub > 0; sub = (sub - 1) & state {
            if sub > remain {
                continue
            }
            if bestPlan[sub] == nil || bestPlan[state ^ sub] == nil {
                continue
            }
            join := buildJoin(bestPlan[sub], bestPlan[state^sub], edges between them)
            if bestCost[state] > join.Cost {
                bestPlan[state] = join
                bestCost[state] = join.Cost
            }
        }
    }
}

• 聚合函数下推（Aggregation Pushdown）：在数据分片节点预先计算部分聚合结果，减少网络传输数据量

物理优化：成本驱动的计划选择

物理优化阶段根据逻辑计划生成多个物理实现方案，并通过成本模型（Cost Model）选择最优方案。关键技术包括：

• 物理算子选择：同一逻辑算子可对应多种物理实现，如Join算子可实现为HashJoin、MergeJoin或IndexJoin
• 分布式任务划分：将执行计划划分为可在TiKV（存储节点）执行的Cop Task和TiDB（计算节点）执行的Root Task
• 数据本地化考虑：优先选择数据所在节点执行计算，减少跨节点数据传输

核心数据结构

Cascades优化框架引入了Group和Group Expression概念管理等价表达式空间：

Group代表一组逻辑等价的表达式，GroupExpr则表示具有相同根算子的等价表达式集合。这种结构允许优化器高效探索所有可能的等价计划。

EXPLAIN语句：执行计划的窗口

EXPLAIN是分析查询计划的主要工具，通过它可以查看TiDB如何解析和执行SQL语句。TiDB提供多种EXPLAIN变体以满足不同分析需求：

EXPLAIN基础用法

-- 基本执行计划
EXPLAIN SELECT * FROM orders JOIN order_items ON orders.id = order_items.order_id WHERE orders.status = 'paid';

-- 包含执行统计信息
EXPLAIN ANALYZE SELECT COUNT(*) FROM products WHERE price > 100;

-- 显示可视化执行计划
EXPLAIN FORMAT = 'dot' SELECT ...;

执行计划输出解读

以下是一个典型的分布式查询执行计划：

+------------------------------+----------+--------------+---------------+------------------------------------------------+
| id                           | estRows  | task         | access object | operator info                                  |
+------------------------------+----------+--------------+---------------+------------------------------------------------+
| HashJoin_8                   | 10000.00 | root         |               | inner join, equal:[eq(test.orders.id, test.order_items.order_id)] |
| ├─TableReader_15             | 100.00   | root         |               | data:Selection_14                              |
| │ └─Selection_14             | 100.00   | cop[tikv]    |               | eq(test.orders.status, "paid")                 |
| │   └─TableFullScan_13       | 10000.00 | cop[tikv]    | table:orders  | keep order:false                               |
| └─TableReader_12             | 100000.00| root         |               | data:TableFullScan_11                          |
|   └─TableFullScan_11         | 100000.00| cop[tikv]    | table:order_items | keep order:false                            |
+------------------------------+----------+--------------+---------------+------------------------------------------------+

关键列解读：

列名	说明
id	算子ID，反映执行顺序（通常自底向上执行）
estRows	估计行数，反映优化器对结果集大小的预测，与实际行数差距过大会影响计划选择
task	任务类型，root表示在TiDB执行，cop[tikv]表示在TiKV执行
access object	访问的对象，如表名和索引名
operator info	算子详细信息，包括连接条件、过滤条件、排序方式等

分布式执行计划特征

分布式执行计划与单机计划的主要区别在于：

1. 多节点任务分布：计划中同时包含在TiDB和TiKV上执行的算子
2. 数据传输算子：如TableReader负责从TiKV读取数据到TiDB
3. 分布式连接策略：根据数据分布选择不同的连接算法，如广播连接或重分区连接

分布式执行计划的关键算子

TiDB执行计划包含多种特殊算子以适应分布式环境，理解这些算子是优化查询性能的基础。

数据访问算子

TableScan与IndexScan

• TableFullScan：全表扫描，性能较差，应尽量避免
• IndexRangeScan：利用索引进行范围查询，效率较高
• IndexLookUp：先扫描索引获取行ID，再回表读取完整行数据

TableReader与IndexReader

这些算子负责在TiDB和TiKV之间协调数据传输：

• 将下推的算子（如Selection、Aggregation）发送到TiKV执行
• 收集TiKV返回的中间结果并传递给上层算子

连接算子

TiDB支持多种连接算法，适用于不同场景：

连接算法	适用场景	分布式特性
HashJoin	大数据集连接，无排序要求	支持将构建端广播到各节点
MergeJoin	已排序数据集，低内存消耗	需保证左右表分区键相同
IndexJoin	小表连接大表，利用索引	可下推至存储节点执行

分布式连接策略

当连接表数据分布在多个节点时，TiDB采用以下策略之一：

1. 广播连接（Broadcast Join）：将小表数据广播到所有包含大表数据的节点

2. 重分区连接（Repartition Join）：根据连接键重新分区两张表的数据

3. 本地化连接（Local Join）：当连接数据已在同一节点时直接本地连接

聚合算子

分布式聚合策略

TiDB采用两步聚合策略减少网络传输：

1. 部分聚合（Partial Aggregation）：在TiKV节点上先进行本地聚合
2. 全局聚合（Global Aggregation）：在TiDB节点汇总各TiKV的聚合结果

-- 部分聚合示例：在TiKV计算每个分区的COUNT和SUM
SELECT COUNT(*) AS cnt, SUM(amount) AS sum FROM orders GROUP BY user_id

-- 全局聚合：汇总所有分区结果
SELECT SUM(cnt) AS total_cnt, SUM(sum) AS total_sum FROM partial_results

执行计划优化实战

常见性能问题诊断

谓词不下推

当过滤条件无法下推到TiKV时，会导致大量无用数据传输。例如：

+-------------------------+---------+--------------+---------------+--------------------------------+
| id                      | estRows | task         | access object | operator info                  |
+-------------------------+---------+--------------+---------------+--------------------------------+
| Selection_6             | 10.00   | root         |               | eq(test.orders.status, "paid") |
| └─TableReader_11        | 1000.00 | root         |               | data:TableFullScan_10          |
|   └─TableFullScan_10    | 1000.00 | cop[tikv]    | table:orders  | keep order:false               |
+-------------------------+---------+--------------+---------------+--------------------------------+

问题在于过滤条件在root任务中执行，而非下推到cop任务。解决方法包括：

1. 确保使用的函数支持下推，如避免使用TiDB特有函数
2. 检查SQL模式设置，某些模式可能禁用谓词下推
3. 验证统计信息是否最新，过时的统计信息可能导致优化器误判

低效连接顺序

连接顺序对分布式查询性能影响巨大。优化器可能因统计信息不准确选择次优连接顺序：

-- 强制连接顺序
SELECT /*+ STRAIGHT_JOIN(t1, t2, t3) */ t1.id, t2.name, t3.value
FROM t1 JOIN t2 ON t1.id = t2.t1_id
JOIN t3 ON t2.id = t3.t2_id;

数据倾斜

分布式环境中，数据倾斜会导致部分节点负载过高：

解决数据倾斜的方法包括：

1. 使用更均匀的分区键
2. 对热点数据进行特殊处理，如拆分热点值
3. 使用TiDB的动态负载均衡功能

执行计划优化技巧

合理使用索引

创建合适的索引是提升查询性能的首要方法：

-- 为频繁过滤和连接的列创建索引
CREATE INDEX idx_orders_status ON orders(status);
CREATE INDEX idx_order_items_order_id ON order_items(order_id);

控制结果集大小

限制返回数据量可显著减少网络传输和计算开销：

-- 只选择需要的列
SELECT id, name FROM products WHERE price > 100;

-- 使用LIMIT分页
SELECT * FROM logs ORDER BY time DESC LIMIT 100;

利用执行计划提示（Hint）

当优化器选择不理想的计划时，可使用Hint强制特定行为：

-- 强制使用指定索引
SELECT /*+ USE_INDEX(t idx_name) */ * FROM t WHERE col = 1;

-- 强制使用HashJoin
SELECT /*+ HASH_JOIN(t1, t2) */ t1.id, t2.value FROM t1 JOIN t2 ON t1.id = t2.t1_id;

-- 强制谓词下推
SELECT /*+ READ_FROM_STORAGE(TIFLASH[t]) */ * FROM t WHERE date > '2023-01-01';

统计信息维护

准确的统计信息是优化器选择最优计划的基础：

-- 更新表统计信息
ANALYZE TABLE orders, order_items;

-- 设置自动更新统计信息
SET GLOBAL tidb_auto_analyze = ON;

高级主题：分布式查询优化的未来趋势

TiDB持续改进查询优化器，以下是几个值得关注的发展方向：

自适应查询执行

传统基于成本的优化依赖于统计信息预测，当预测与实际情况不符时，查询性能会下降。自适应查询执行（Adaptive Query Execution）允许在执行过程中动态调整计划：

• 运行时统计收集：在查询执行过程中收集实际数据分布信息
• 计划动态调整：根据实际数据分布切换更优的执行策略
• 反馈机制：将执行过程中的信息反馈给优化器，改进未来计划

智能索引推荐

TiDB的Index Advisor功能可自动分析工作负载并推荐最优索引：

-- 分析SQL workload并推荐索引
ADVISE INDEX FOR
    SELECT * FROM orders WHERE status = 'paid' AND create_time > '2023-01-01';

内存管理与资源控制

TiDB 6.0引入了全局内存控制（Global Memory Control）机制，避免单个查询过度消耗资源：

总结与展望

TiDB执行计划是分布式查询性能的核心，理解其生成机制和优化原理对于数据库管理员和开发人员至关重要。本文介绍了TiDB优化器的Cascades架构、EXPLAIN工具使用、关键算子特性及优化技巧，为你提供了分布式查询性能调优的系统方法。

随着数据量的增长和业务复杂度的提升，查询优化将成为持续的挑战。未来TiDB优化器将在以下方面继续发展：

• 更精准的成本模型，结合机器学习技术
• 更智能的分布式执行策略
• 与存储层（如TiFlash）更紧密的协同优化

掌握执行计划分析能力，将帮助你在分布式数据库环境中应对各种性能挑战，充分发挥TiDB的分布式优势。

附录：常用工具与资源

1. 执行计划可视化工具：TiDB Dashboard提供的执行计划可视化功能
2. 性能监控：通过Prometheus和Grafana监控查询执行指标
3. 官方文档：TiDB查询优化指南
4. 社区资源：TiDB GitHub仓库中的设计文档和优化案例

记住，优秀的查询性能不是一蹴而就的，而是持续分析、优化和学习的过程。通过不断实践本文介绍的方法，你将能够构建高效、稳定的分布式数据库应用。

【免费下载链接】tidb TiDB 是一个分布式关系型数据库，兼容 MySQL 协议。* 提供水平扩展能力；支持高并发、高可用、在线 DDL 等特性。* 特点：分布式架构设计；支持 MySQL 生态；支持 SQL 和 JSON 数据类型。 项目地址: https://gitcode.com/GitHub_Trending/ti/tidb