前言

很多开发、DBA 在从 MySQL 迁移 TiDB、或者日常 TiDB 调优时，最大的痛点：
会看 MySQL 的 Explain，但是完全看不懂 TiDB 的 Explain，调优无从下手。
本质原因：
MySQL 是单机执行模型，TiDB 是分布式执行模型，两者的执行计划逻辑、字段含义、优化侧重点完全不一样。

本文一次性讲透：

1. MySQL 与 TiDB 执行计划核心区别

2. 字段一一映射对照表（快速上手）

3. 常见 SQL 问题在两种 Explain 中的对应表现

4. TiDB 专属慢 SQL 排查 + 调优命令大全（生产直接复制）

适合收藏：面试、迁移、日常慢 SQL 优化、TiDB 运维 全场景通用。

一、核心认知：两者执行模型根本不同

1. MySQL 执行模型（单机）

• 架构：Server层 + InnoDB存储引擎

• 计算特点：大部分计算在 MySQL Server 层执行

• Explain 核心关注点：

◦ 索引有没有命中

◦ 是否全表扫描

◦ 是否文件排序、临时表

• 一句话总结：看这条 SQL 在单机会不会慢

2. TiDB 执行模型（分布式）

• 架构：TiDB（计算） + TiKV（分布式存储）

• 核心机制：计算尽可能下推 TiKV 执行（Coprocessor 协处理器）

• Explain 核心关注点：

◦ 算子是否下推 cop[tikv]

◦ 哪些计算留在 root 节点（网关汇总）

◦ 统计信息是否准确

◦ 分布式任务拆分是否合理

• 一句话总结：看这条 SQL 在集群里分摊得匀不匀、网络开销大不大
关键结论：
MySQL 慢，多半是索引烂了；
TiDB 慢，多半是 没下推、统计不准、大量计算上 root。

二、MySQL Explain VS TiDB Explain 字段精准映射

1. 字段一一对应速查表

MySQL 字段 TiDB 等价含义 解读要点 
id 算子缩进ID 缩进越深越先执行，自底向上 
select_type 算子类型（Agg/Join/Union） 区分普通查询、子查询、聚合 
table access object 对应表、索引、分区 
type 扫描算子类型 TableFullScan / IndexScan / IndexRangeScan 
key 实际使用索引 在 operator info 中查看索引名 
rows estRows（预估行数） 偏差大=统计信息过时 
filtered 过滤选择性 内置在算子 filter 逻辑中 
Extra task + operator info TiDB 调优最核心字段 

2. 两种 Explain 阅读逻辑差异

• MySQL 阅读顺序：从上到下，看 type > key > Extra

• TiDB 阅读顺序：从下到上，看 cop[tikv] / root 算子树

三、MySQL 经典慢SQL特征，对应 TiDB 表现

1. MySQL：Using filesort（文件排序）

• 问题：无法利用索引有序，Server 层排序

• TiDB 对应现象：

◦ 出现独立 Sort 算子

◦ 且 task=root（最致命，全网数据拉到 TiDB 排序）

• 优化：加联合索引，让排序在 TiKV 本地完成

2. MySQL：Using temporary（临时表）

• 问题：分组、去重、关联产生临时表

• TiDB 对应现象：

◦ HashAgg / HashJoin 大量上 root 节点

◦ 内存消耗高、网络吞吐大

3. MySQL：Using index（覆盖索引）

• 优势：无需回表

• TiDB 对应现象：

◦ 只有 IndexScan，无 TableReader

◦ 100% 下推 TiKV，性能最优

4. MySQL：type=ALL 全表扫描

• TiDB 对应：TableFullScan

• 生产大忌：大表全扫、无法分片过滤

四、TiDB 独有核心字段（调优必看）

1. task 字段（TiDB 灵魂）

• cop[tikv]：计算下推存储节点 ✅ 最优

• root：TiDB 网关汇总计算 ❌ 尽量减少
TiDB 优化第一准则：
能下推的全部下推，不让数据上来！

2. keep order

• keep order:true：扫描自带有序，无需二次排序

• keep order:false：无序返回，上层需要 Sort

3. stats:pseudo

• 伪统计信息 = 优化器瞎猜行数

• 直接导致执行计划错乱、索引选错、超级慢

• 解决方案：ANALYZE TABLE xxx;

4. EXPLAIN ANALYZE（TiDB 神器）

MySQL 无官方真实执行计划；
TiDB 可以 真实执行 SQL，展示实际行数、耗时、KV扫描次数，是调优第一工具。

五、TiDB 生产慢SQL排查全套命令（可直接复制）

1. 查看真实执行计划（首选）

-- 预估计划（不执行）
EXPLAIN SELECT * FROM test.t1 WHERE id>100;
-- 真实执行 + 耗时分析（调优必用）
EXPLAIN ANALYZE SELECT * FROM test.t1 WHERE id>100;

2. 慢查询日志分析

-- 查看慢查询配置
SHOW VARIABLES LIKE 'slow_query%';
SHOW VARIABLES LIKE 'long_query_time';

-- 临时调低阈值，抓更多慢SQL
SET GLOBAL long_query_time=0.1;

-- 查询集群慢SQL Top20
SELECT * FROM INFORMATION_SCHEMA.CLUSTER_SLOW_QUERY 
WHERE query_time > 0.1 
ORDER BY query_time DESC LIMIT 20;

3. 统计信息修复（解决90%计划跑偏）

-- 单表刷新统计
ANALYZE TABLE 库名.表名;

-- 整库刷新
ANALYZE DATABASE 库名;

-- 查看统计元信息
SHOW STATS_META WHERE table_name='表名';

4. 索引排查 & 无用索引清理

-- 查看表索引
SHOW INDEX FROM 库名.表名;

-- 查看索引实际使用率
SELECT * FROM INFORMATION_SCHEMA.TIDB_INDEX_USAGE;

5. hint 强制优化（应急救急）

-- 强制走指定索引
SELECT /*+ USE_INDEX(t,idx_col) */ * FROM 表名 t;

-- 禁止全表扫描
SELECT /*+ NO_FULL_TABLE_SCAN() */ * FROM 表名;

-- 强制合并连接（有序表关联更快）
SELECT /*+ MERGE_JOIN(a,b) */ * FROM t1 a JOIN t2 b ON a.id=b.tid;

6. 会话阻塞 & 杀会话

-- 查看活跃会话
SHOW PROCESSLIST;

-- 终止卡死慢查询
KILL 会话ID;

-- 查看集群节点负载
SHOW TIDB_SERVERS;

7. 分区裁剪排查

EXPLAIN PARTITIONS SELECT * FROM 分区表 WHERE pt='202605';

六、终极调优口诀（日常排查直接套）

MySQL 调优口诀：优先 ref、杜绝全表、少排序、少临时表

TiDB 调优口诀：：多看 cop 少 root、索引扫描优先走、统计过期马上更、聚合排序尽量下沉

七、总结

1. MySQL Explain 看索引与单机开销；

2. TiDB Explain 看分布式下推与集群任务拆分；

3. TiDB 慢 SQL 90% 问题来自：未下推 + 统计信息失效 + 大量 root 计算；

4. 生产调优固定流程：EXPLAIN ANALYZE → 检查下推 → 校验统计 → 加索引下沉计算。
适合场景

• 面试回答 TiDB 与 MySQL 优化区别

• 业务 MySQL 迁移 TiDB 适配

• 日常 DBA 慢 SQL 排查手册

• 团队内部技术沉淀文档