performance tuning: change SQL tuning TOC (pingcap#4662)

TOC.md

@@ -111,9 +111,10 @@
     + [下推计算结果缓存](/coprocessor-cache.md)
   + SQL 性能调优
     + [SQL 性能调优概览](/sql-tuning-overview.md)
-    + [理解 TiDB 执行计划](/query-execution-plan.md)
-    + SQL 优化
-      + [SQL 优化流程简介](/sql-optimization-concepts.md)
+    + 理解 TiDB 执行计划
+      + [TiDB 执行计划概览](/explain-overview.md)
+    + SQL 优化流程
+      + [SQL 优化流程概览](/sql-optimization-concepts.md)
       + 逻辑优化
         + [逻辑优化概览](/sql-logical-optimization.md)
         + [子查询相关的优化](/subquery-optimization.md)
@@ -131,11 +132,11 @@
         + [错误索引的解决方案](/wrong-index-solution.md)
         + [Distinct 优化](/agg-distinct-optimization.md)
       + [执行计划缓存](/sql-prepare-plan-cache.md)
-      + 控制执行计划
-        + [控制执行计划概览](/control-execution-plan.md)
-        + [Optimizer Hints](/optimizer-hints.md)
-        + [执行计划管理](/sql-plan-management.md)
-        + [优化规则及表达式下推的黑名单](/blacklist-control-plan.md)
+    + 控制执行计划
+      + [控制执行计划概览](/control-execution-plan.md)
+      + [Optimizer Hints](/optimizer-hints.md)
+      + [执行计划管理](/sql-plan-management.md)
+      + [优化规则及表达式下推的黑名单](/blacklist-control-plan.md)
 + 教程
   + [同城多中心部署](/multi-data-centers-in-one-city-deployment.md)
   + [两地三中心部署](/three-data-centers-in-two-cities-deployment.md)

analyze-slow-queries.md

@@ -242,7 +242,7 @@ mysql> explain select * from t t1, t t2 where t1.a>t2.a;
 4. `select b from t where c=3`：多列索引没有前缀条件就用不上，所以会用 `IndexFullScan`；
 5. ...
 
-上面举例了数据读入相关的算子，在 [理解 TiDB 执行计划](/query-execution-plan.md) 中描述了更多算子的情况；
+上面举例了数据读入相关的算子，在 [理解 TiDB 执行计划](/explain-overview.md) 中描述了更多算子的情况；
 
 另外阅读 [SQL 性能调优](/sql-tuning-overview.md) 整个小节能增加你对 TiDB 优化器的了解，帮助判断执行计划是否合理。
 

blacklist-control-plan.md

@@ -133,14 +133,14 @@ desc mysql.expr_pushdown_blacklist;
 2. 执行 `admin reload expr_pushdown_blacklist;`。
 
 > **注意：**
-> 
+>
 > `admin reload expr_pushdown_blacklist` 只对执行该 SQL 语句的 TiDB server 生效。若需要集群中所有 TiDB server 生效，需要在每台 TiDB server 上执行该 SQL 语句。
 
 ### 表达式黑名单用法示例
 
 以下示例首先将运算符 `<` 及 `>` 加入黑名单，然后将运算符 `>` 从黑名单中移出。
 
-黑名单是否生效可以从 `explain` 结果中进行观察（参见[`EXPLAIN` 简介](/query-execution-plan.md#explain-简介)）。
+黑名单是否生效可以从 `explain` 结果中进行观察（参见 [`EXPLAIN` 简介](/explain-overview.md#explain-简介)）。
 
 1. 对于以下 SQL 语句，`where` 条件中的 `a < 2` 和 `a > 2` 可以下推到 TiKV 进行计算。
 

dashboard/dashboard-slow-query.md

@@ -49,7 +49,7 @@ aliases: ['/docs-cn/dev/dashboard/dashboard-slow-query/']
 在列表中点击任意一行可以显示该慢查询的详细执行信息，包含：
 
 - SQL：慢查询 SQL 文本（下图中区域 1）
-- 执行计划：慢查询的执行计划，参阅[理解 TiDB 执行计划](/query-execution-plan.md)文档了解如何解读执行计划（下图中区域 2）
+- 执行计划：慢查询的执行计划，参阅[理解 TiDB 执行计划](/explain-overview.md)文档了解如何解读执行计划（下图中区域 2）
 - 其他分类好的 SQL 执行信息（下图中区域 3）
 
 ![查看执行详情](/media/dashboard/dashboard-slow-queries-detail1.png)

dashboard/dashboard-statement-details.md

@@ -19,7 +19,7 @@ aliases: ['/docs-cn/dev/dashboard/dashboard-statement-details/','/docs-cn/dev/da
 执行计划详情包括以下内容：
 
 - SQL 样本：该计划对应的实际执行的某一条 SQL 语句文本。时间范围内任何出现过的 SQL 都可能作为 SQL 样本。
-- 执行计划：执行计划的完整内容，参阅[理解 TiDB 执行计划](/query-execution-plan.md)文档了解如何解读执行计划。如果选择了多个执行计划，则显示的是其中任意一个。
+- 执行计划：执行计划的完整内容，参阅[理解 TiDB 执行计划](/explain-overview.md)文档了解如何解读执行计划。如果选择了多个执行计划，则显示的是其中任意一个。
 - 其他关于该 SQL 的基本信息、执行时间、Coprocessor 读取、事务、慢查询等信息，可点击相应标签页标题切换。
 
 ![执行计划详情](/media/dashboard/dashboard-statement-plans-detail.png)

query-execution-plan.md → explain-overview.md

@@ -1,13 +1,14 @@
 ---
-title: 理解 TiDB 执行计划
+title: EXPLAIN 概览
+summary: 了解 TiDB 中 EXPLAIN 语句返回的执行计划。
 aliases: ['/docs-cn/dev/query-execution-plan/','/docs-cn/dev/reference/performance/understanding-the-query-execution-plan/','/docs-cn/dev/index-merge/','/docs-cn/dev/reference/performance/index-merge/','/zh/tidb/dev/query-execution-plan/']
 ---
 
-# 理解 TiDB 执行计划
+# `EXPLAIN` 概览
 
 TiDB 优化器会根据当前数据表的最新的统计信息来选择最优的执行计划，执行计划由一系列的算子构成。本文将详细解释 TiDB 中的执行计划。
 
-## EXPLAIN 简介
+## `EXPLAIN` 简介
 
 TiDB 中可以使用 `EXPLAIN` 命令来查看执行计划，`EXPLAIN` 语句的返回结果提供了 TiDB 执行 SQL 查询的详细信息：
 

faq/sql-faq.md

@@ -208,7 +208,7 @@ TiDB 在执行 SQL 语句时，会使用当时的 `schema` 来处理该 SQL 语
 
 ### TiDB 执行计划解读
 
-详细解读[理解 TiDB 执行计划](/query-execution-plan.md)。
+详细解读[理解 TiDB 执行计划](/explain-overview.md)。
 
 ### 统计信息收集
 
@@ -263,11 +263,11 @@ RUNNING_JOBS: ID:121, Type:add index, State:running, SchemaState:write reorganiz
 
 ### SQL 的执行计划展开成了树，ID 的序号有什么规律吗？这棵树的执行顺序会是怎么样的？
 
-ID 没什么规律，只要是唯一就行，不过生成的时候，是有一个计数器，生成一个 plan 就加一，执行的顺序和序号无关，整个执行计划是一颗树，执行时从根节点开始，不断地向上返回数据。执行计划的理解，请参考[理解 TiDB 执行计划](/query-execution-plan.md)。
+ID 没什么规律，只要是唯一就行，不过生成的时候，是有一个计数器，生成一个 plan 就加一，执行的顺序和序号无关，整个执行计划是一颗树，执行时从根节点开始，不断地向上返回数据。执行计划的理解，请参考[理解 TiDB 执行计划](/explain-overview.md)。
 
 ### TiDB 执行计划中，task cop 在一个 root 下，这个是并行的么？
 
-目前 TiDB 的计算任务隶属于两种不同的 task：cop task 和 root task。cop task 是指被下推到 KV 端分布式执行的计算任务，root task 是指在 TiDB 端单点执行的计算任务。一般来讲 root task 的输入数据是来自于 cop task 的；但是 root task 在处理数据的时候，TiKV 上的 cop task 也可以同时处理数据，等待 TiDB 的 root task 拉取，所以从这个观点上来看，他们是并行的；但是存在数据上下游关系；在执行的过程中，某些时间段其实也是并行的，第一个 cop task 在处理 [100, 200] 的数据，第二个 cop task 在处理 [1, 100] 的数据。执行计划的理解，请参考[理解 TiDB 执行计划](/query-execution-plan.md)。
+目前 TiDB 的计算任务隶属于两种不同的 task：cop task 和 root task。cop task 是指被下推到 KV 端分布式执行的计算任务，root task 是指在 TiDB 端单点执行的计算任务。一般来讲 root task 的输入数据是来自于 cop task 的；但是 root task 在处理数据的时候，TiKV 上的 cop task 也可以同时处理数据，等待 TiDB 的 root task 拉取，所以从这个观点上来看，他们是并行的；但是存在数据上下游关系；在执行的过程中，某些时间段其实也是并行的，第一个 cop task 在处理 [100, 200] 的数据，第二个 cop task 在处理 [1, 100] 的数据。执行计划的理解，请参考[理解 TiDB 执行计划](/explain-overview.md)。
 
 ## 数据库优化
 

functions-and-operators/expressions-pushed-down.md

@@ -68,7 +68,7 @@ tidb> desc mysql.expr_pushdown_blacklist;
 
 以下示例首先将运算符 `<` 及 `>` 加入黑名单，然后将运算符 `>` 从黑名单中移出。
 
-黑名单是否生效可以从 `explain` 结果中进行观察（参见[如何理解 `explain` 结果](/query-execution-plan.md)）。
+黑名单是否生效可以从 `explain` 结果中进行观察（参见[如何理解 `explain` 结果](/explain-overview.md)）。
 
 ```sql
 tidb> create table t(a int);

mysql-compatibility.md

@@ -82,7 +82,7 @@ TiDB 主要使用 Prometheus 和 Grafana 来存储及查询相关的性能监控
 
 ### 查询计划
 
-`EXPLAIN`/`EXPLAIN FOR` 输出格式、内容、权限设置与 MySQL 有比较大的差别，参见[理解 TiDB 执行计划](/query-execution-plan.md)。
+`EXPLAIN`/`EXPLAIN FOR` 输出格式、内容、权限设置与 MySQL 有比较大的差别，参见[理解 TiDB 执行计划](/explain-overview.md)。
 
 ### 内建函数
 

sql-physical-optimization.md

@@ -7,7 +7,7 @@ aliases: ['/docs-cn/dev/sql-physical-optimization/']
 
 物理优化是基于代价的优化，为上一阶段产生的逻辑执行计划制定物理执行计划。这一阶段中，优化器会为逻辑执行计划中的每个算子选择具体的物理实现。逻辑算子的不同物理实现有着不同的时间复杂度、资源消耗和物理属性等。在这个过程中，优化器会根据数据的统计信息来确定不同物理实现的代价，并选择整体代价最小的物理执行计划。
 
-[理解 TiDB 执行计划](/query-execution-plan.md) 文档已对每个物理算子进行了一些介绍。在本章我们会重点介绍以下方面：
+[理解 TiDB 执行计划](/explain-overview.md) 文档已对每个物理算子进行了一些介绍。在本章我们会重点介绍以下方面：
 
 - 在[索引的选择](/choose-index.md)中会介绍 TiDB 在一张表有多个索引时，如何选择最优的索引进行表的访问。
 - 在[统计信息简介](/statistics.md)中会介绍 TiDB 收集了哪些统计信息来获得表的数据分布情况

sql-statements/sql-statement-explain-analyze.md

@@ -97,7 +97,7 @@ EXPLAIN ANALYZE SELECT * FROM t1;
 
 ## 另请参阅
 
-* [Understanding the Query Execution Plan](/query-execution-plan.md)
+* [Understanding the Query Execution Plan](/explain-overview.md)
 * [EXPLAIN](/sql-statements/sql-statement-explain.md)
 * [ANALYZE TABLE](/sql-statements/sql-statement-analyze-table.md)
 * [TRACE](/sql-statements/sql-statement-trace.md)

sql-statements/sql-statement-explain.md

@@ -248,7 +248,7 @@ The `xx.dot` is the result returned by the above statement.
 
 ## 另请参阅
 
-* [Understanding the Query Execution Plan](/query-execution-plan.md)
+* [理解 TiDB 执行计划](/explain-overview.md)
 * [EXPLAIN ANALYZE](/sql-statements/sql-statement-explain-analyze.md)
 * [ANALYZE TABLE](/sql-statements/sql-statement-analyze-table.md)
 * [TRACE](/sql-statements/sql-statement-trace.md)

sql-tuning-overview.md

@@ -5,8 +5,12 @@ aliases: ['/docs-cn/dev/sql-tuning-overview/']
 
 # SQL 性能调优
 
-在上一章节”故障诊断“中，介绍了可以通过一些手段定位到对集群造成影响的一些查询，或是 DBA 主动发现某些查询的执行时间不符合原本的预期，这时就需要对查询的执行情况进行分析。在本章中主要有以下三个部分，介绍了如何针对一个具体的查询进行调优：
+SQL 是一种声明性语言。一条 SQL 语句描述的是最终结果应该如何，而非按顺序执行的步骤。TiDB 会优化 SQL 语句的执行，语义上允许以任何顺序执行查询的各部分，前提是能正确返回语句所描述的最终结果。
 
-- 第一部分[理解 TiDB 执行计划](/query-execution-plan.md)中，会介绍如何使用 `EXPLAIN` 以及 `EXPLAIN ANALYZE` 语句来理解 TiDB 是如何执行某个查询的。
-- 第二部分[SQL 优化流程简介](/sql-optimization-concepts.md)中，会介绍 TiDB 内部会使用的优化，其中会涉及一些等价的 SQL 变换以及物理计划的选择，来方便读者理解 TiDB 是如何生成最终的执行计划的。
-- 第三部分[控制执行计划](/control-execution-plan.md)中，会介绍如何通过一些手段来控制执行计划的生成来提升查询的执行速度，减少它对集群整体性能或者业务的影响情况。
+SQL 性能优化的过程，可以理解为 GPS 导航的过程。你提供地址后，GPS 软件利用各种统计信息（例如以前的行程、速度限制等元数据，以及实时交通信息）规划出一条最省时的路线。这与 TiDB 中的 SQL 性能优化过程相对应。
+
+本章节包括以下文档，可帮助你更好地理解查询执行计划：
+
+- [理解 TiDB 执行计划](/explain-overview.md)介绍如何使用 `EXPLAIN` 语句来理解 TiDB 是如何执行某个查询的。
+- [SQL 优化流程概览](/sql-optimization-concepts.md)介绍 TiDB 可以使用的几种优化，以提高查询性能。
+- [控制执行计划](/control-execution-plan.md)介绍如何控制执行计划的生成。TiDB 的执行计划非最优时，建议控制执行计划。

subquery-optimization.md

@@ -18,7 +18,7 @@ aliases: ['/docs-cn/dev/subquery-optimization/']
 
 有时，子查询中包含了非子查询中的列，如 `select * from t where t.a in (select * from t2 where t.b=t2.b)` 中，子查询中的 `t.b` 不是子查询中的列，而是从子查询外面引入的列。这种子查询通常会被称为`关联子查询`，外部引入的列会被称为`关联列`，关联子查询相关的优化参见[关联子查询去关联](/correlated-subquery-optimization.md)。本文主要关注不涉及关联列的子查询。
 
-子查询默认会以[理解 TiDB 执行计划](/query-execution-plan.md)中提到的 `semi join` 作为默认的执行方式，同时对于一些特殊的子查询，TiDB 会做一些逻辑上的替换使得查询可以获得更好的执行性能。
+子查询默认会以[理解 TiDB 执行计划](/explain-overview.md)中提到的 `semi join` 作为默认的执行方式，同时对于一些特殊的子查询，TiDB 会做一些逻辑上的替换使得查询可以获得更好的执行性能。
 
 ## `... < ALL (SELECT ... FROM ...)` 或者 `... > ANY (SELECT ... FROM ...)`
 

whats-new-in-tidb-4.0.md

@@ -51,7 +51,7 @@ TiUP 是 4.0 版本中新推出的包管理器的工具，主要用于管理 TiD
 - 新增 `Flashback` 命令，支持恢复被 `Truncate` 的表。详情参阅：[`Flashback`](/sql-statements/sql-statement-flashback-table.md)。
 - 新增查询数据时将 Join、Sort 中间结果写入本地磁盘，防止查询语句占用内存过多导致系统 OOM 的问题，提升系统的稳定性。
 - 优化 `EXPLAIN` 和 `EXPLAIN ANALYZE` 的输出结果，显示更多的信息，提升排查问题的效率。详情参阅：[Explain Analyze](/sql-statements/sql-statement-explain-analyze.md)，[Explain](/sql-statements/sql-statement-explain.md)。
-- 支持 Index Merge 功能，Index Merge 是一种新的表访问方式，当查询只涉及到单张表时，优化器会自动根据查询条件读取多个索引数据并对结果求并集，提升查询单张表时的性能。详情参阅：[Index Merge](/query-execution-plan.md#indexmerge-示例)。
+- 支持 Index Merge 功能，Index Merge 是一种新的表访问方式，当查询只涉及到单张表时，优化器会自动根据查询条件读取多个索引数据并对结果求并集，提升查询单张表时的性能。详情参阅：[Index Merge](/explain-overview.md#indexmerge-示例)。
 - 支持 AutoRandom Key 作为 TiDB 在列属性上的扩展语法，AutoRandom 被设计用于解决自增主键列的写热点问题，为使用自增主键列的用户提供最低成本的 MySQL 迁移方案。详情参阅：[AutoRandom Key](/auto-random.md)。
 - 新增集群拓扑、配置信息、日志信息、硬件信息、操作系统信息、慢查询信息等系统表等，帮助 DBA 通过 SQL 快速了解、分析系统的各项指标，详情参阅：[information_schema](/information-schema/information-schema.md)，具体信息如下：