rename blacklist-control-plan to blocklist-control-plan (#5549) (#5552)

* cherry pick #5549 to release-5.0

Signed-off-by: ti-srebot <ti-srebot@pingcap.com>

* Apply suggestions from code review

Co-authored-by: xufei <xufei@pingcap.com>
Co-authored-by: TomShawn <41534398+TomShawn@users.noreply.github.com>

TOC.md

@@ -122,7 +122,7 @@
       + [控制执行计划概览](/control-execution-plan.md)
       + [Optimizer Hints](/optimizer-hints.md)
       + [执行计划管理](/sql-plan-management.md)
-      + [优化规则及表达式下推的黑名单](/blacklist-control-plan.md)
+      + [优化规则及表达式下推的黑名单](/blocklist-control-plan.md)
 + 教程
   + [同城多中心部署](/multi-data-centers-in-one-city-deployment.md)
   + [两地三中心部署](/three-data-centers-in-two-cities-deployment.md)

analyze-slow-queries.md

@@ -250,4 +250,4 @@ mysql> explain select * from t t1, t t2 where t1.a>t2.a;
 
 1. [索引选择错误](/wrong-index-solution.md)
 2. [Join 顺序错误](/join-reorder.md)
-3. [表达式未下推](/blacklist-control-plan.md)
+3. [表达式未下推](/blocklist-control-plan.md)

blacklist-control-plan.md → blocklist-control-plan.md

@@ -1,6 +1,7 @@
 ---
 title: 优化规则与表达式下推的黑名单
 summary: 了解优化规则与表达式下推的黑名单。
+aliases: ['/zh/tidb/v5.0/blacklist-control-plan']
 ---
 
 # 优化规则与表达式下推的黑名单

column-pruning.md

@@ -16,4 +16,4 @@ select a from t where b > 5
 
 在该查询的过程中，t 表实际上只有 a, b 两列会被用到，而 c, d 的数据则显得多余。对应到该语句的查询计划，Selection 算子会用到 b 列，下面接着的 DataSource 算子会用到 a, b 两列，而剩下 c, d 两列则都可以裁剪掉，DataSource 算子在读数据时不需要将它们读进来。
 
-出于上述考量，TiDB 会在逻辑优化阶段进行自上而下的扫描，裁剪不需要的列，减少资源浪费。该扫描过程称作 “列裁剪”，对应逻辑优化规则中的 `columnPruner`。如果要关闭这个规则，可以在参照[优化规则及表达式下推的黑名单](/blacklist-control-plan.md)中的关闭方法。
+出于上述考量，TiDB 会在逻辑优化阶段进行自上而下的扫描，裁剪不需要的列，减少资源浪费。该扫描过程称作 “列裁剪”，对应逻辑优化规则中的 `columnPruner`。如果要关闭这个规则，可以在参照[优化规则及表达式下推的黑名单](/blocklist-control-plan.md)中的关闭方法。

control-execution-plan.md

@@ -8,4 +8,4 @@ SQL 性能调优的前两个章节介绍了如何理解 TiDB 的执行计划以
 
 - [Optimizer Hints](/optimizer-hints.md)中，我们会介绍如何使用 Hint 来指导 TiDB 生成执行计划。
 - 但是使用 Hint 会侵入性地更改 SQL，在一些场景下并不能简单的插入 Hint。在[执行计划管理](/sql-plan-management.md)中，我们会介绍 TiDB 如何使用另一种语法来非侵入地控制执行计划的生成，同时还会介绍后台自动对执行计划进行演进的手段，来减轻诸如版本升级等原因造成的执行计划不稳定，而导致集群性能下降的问题。
-- 最后在[优化规则及表达式下推的黑名单](/blacklist-control-plan.md)中，我们会介绍黑名单的使用。
+- 最后在[优化规则及表达式下推的黑名单](/blocklist-control-plan.md)中，我们会介绍黑名单的使用。

correlated-subquery-optimization.md

@@ -17,7 +17,7 @@ TiDB 之所以要进行这样的改写，是因为关联子查询每次子查询
 
 这种改写的弊端在于，在关联没有被解除时，优化器是可以使用关联列上的索引的。也就是说，虽然这个子查询可能被重复执行多次，但是每次都可以使用索引过滤数据。而解除关联的变换上，通常是会导致关联列的位置发生改变而导致虽然子查询只被执行了一次，但是单次执行的时间会比没有解除关联时的单次执行时间长。
 
-因此，在外部的值比较少的情况下，不解除关联依赖反而可能对执行性能更优帮助。这时可以通过[优化规则及表达式下推的黑名单](/blacklist-control-plan.md)中关闭`子查询去关联`优化规则的方式来关闭这个优化。
+因此，在外部的值比较少的情况下，不解除关联依赖反而可能对执行性能更优帮助。这时可以通过[优化规则及表达式下推的黑名单](/blocklist-control-plan.md)中关闭`子查询去关联`优化规则的方式来关闭这个优化。
 
 ## 样例
 

tiflash/use-tiflash.md

@@ -235,7 +235,7 @@ set @@session.tidb_opt_broadcast_join=1
 round without fraction, cast(int as decimal), date_add(datetime, int), date_add(datetime, string), min, max, sum, count, avg, approx_count_distinct
 ```
 
-其中，`cast` 和 `date_add` 的下推默认不开启，若需要手动开启，请参考[优化规则及表达式下推的黑名单](/blacklist-control-plan.md)
+其中，`cast` 和 `date_add` 的下推默认不开启，若需要手动开启，请参考[优化规则及表达式下推的黑名单](/blocklist-control-plan.md)
 
 目前 TiFlash 不支持下推的情况包括：
 

topn-limit-push-down.md

@@ -8,7 +8,7 @@ SQL 中的 LIMIT 子句在 TiDB 查询计划树中对应 Limit 算子节点，OR
 
 和谓词下推类似，TopN（及 Limit，下同）下推将查询计划树中的 TopN 计算尽可能下推到距离数据源最近的地方，以尽早完成数据的过滤，进而显著地减少数据传输或计算的开销。
 
-如果要关闭这个规则，可参照[优化规则及表达式下推的黑名单](/blacklist-control-plan.md)中的关闭方法。
+如果要关闭这个规则，可参照[优化规则及表达式下推的黑名单](/blocklist-control-plan.md)中的关闭方法。
 
 ## 示例