Last bulk of special week changes

TOC.md

@@ -11,6 +11,7 @@
   + [Basic Features](/basic-features.md)
   + [MySQL Compatibility](/mysql-compatibility.md)
   + [TiDB Limitations](/tidb-limitations.md)
+  + [Credits](/credits.md)
 + Quick Start
   + [Try Out TiDB](/quick-start-with-tidb.md)
   + [Learn TiDB SQL](/basic-sql-operations.md)
@@ -106,25 +107,29 @@
       + [TiFlash Tuning](/tiflash/tune-tiflash-performance.md)
     + [Coprocessor Cache](/coprocessor-cache.md)
   + SQL Tuning
+    + [Overview](/sql-tuning-overview.md)
     + [SQL Tuning with `EXPLAIN`](/query-execution-plan.md)
     + SQL Optimization
       + [SQL Optimization Process](/sql-optimization-concepts.md)
       + Logic Optimization
+        + [Overview](/sql-logical-optimization.md)
         + [Subquery Related Optimizations](/subquery-optimization.md)
         + [Column Pruning](/column-pruning.md)
         + [Decorrelation of Correlated Subquery](/correlated-subquery-optimization.md)
         + [Eliminate Max/Min](/max-min-eliminate.md)
-        + [Predicates Push Down](/predicates-push-down.md)
+        + [Predicates Push Down](/predicate-push-down.md)
         + [Partition Pruning](/partition-pruning.md)
         + [TopN and Limit Push Down](/topn-limit-push-down.md)
         + [Join Reorder](/join-reorder.md)
       + Physical Optimization
+        + [Overview](/sql-physical-optimization.md)
         + [Index Selection](/choose-index.md)
         + [Statistics](/statistics.md)
         + [Wrong Index Solution](/wrong-index-solution.md)
         + [Distinct Optimization](/agg-distinct-optimization.md)
       + [Prepare Execution Plan Cache](/sql-prepare-plan-cache.md)
       + Control Execution Plan
+        + [Overview](/control-execution-plan.md)
         + [Optimizer Hints](/optimizer-hints.md)
         + [SQL Plan Management](/sql-plan-management.md)
         + [The Blocklist of Optimization Rules and Expression Pushdown](/blocklist-control-plan.md)

control-execution-plan.md

@@ -0,0 +1,11 @@
+---
+title: Control Execution Plan
+---
+
+# Control Execution Plan
+
+The first two chapters of SQL Tuning introduce how to understand TiDB's execution plan and how TiDB generates an execution plan. This chapter introduces what methods can be used to control the generation of the execution plan when you determine the problems with the execution plan. This chapter mainly includes the following three aspects:
+
+- In [Optimizer Hints](/optimizer-hints.md), you will learn how to use hints to guide TiDB to generate an execution plan.
+- But hints change the SQL statement intrusively. In some scenarios, hints cannot be simply inserted. In [SQL Plan Management](/sql-plan-management.md), you will know how TiDB uses another syntax to non-intrusively control the generation of execution plans, and the methods of automatic execution plan evolution in the background to alleviate the execution plan instability caused by reasons such as version upgrades, which degrades cluster performance.
+- Finally, you will learn how to use the blocklist in [Blocklist of Optimization Rules and Expression Pushdown](/blocklist-control-plan.md).

predicates-push-down.md → predicate-push-down.md

@@ -1,6 +1,7 @@
 ---
 title: Predicates Push Down
 summary: Introduce one of the TiDB's logic optimization rules—Predicate Push Down (PPD).
+aliases: ['/tidb/dev/predicates-push-down']
 ---
 
 # Predicates Push Down (PPD)

sql-logical-optimization.md

@@ -0,0 +1,18 @@
+---
+title: SQL Logical Optimization
+---
+
+# SQL Logical Optimization
+
+This chapter explains some key logic rewrites to help you understand how TiDB generates the final query plan. For example, when you execute the `select * from t where t.a in (select * from t1 where t1.b=t.b)` query in TiDB, you will find that the `IN` sub-query `t.a in (select t1.a from t1 where t1.b=t.b` does not exist because TiDB has made some rewrites here.
+
+This chapter introduces the following key rewrites:
+
+- [Subquery Related Optimizations](/subquery-optimization.md)
+- [Column Pruning](/column-pruning.md)
+- [Decorrelation of Correlated Subquery](/correlated-subquery-optimization.md)
+- [Eliminate Max/Min](/max-min-eliminate.md)
+- [Predicates Push Down](/predicate-push-down.md)
+- [Partition Pruning](/partition-pruning.md)
+- [TopN and Limit Operator Push Down](/topn-limit-push-down.md)
+- [Join Reorder](/join-reorder.md)

sql-optimization-concepts.md

@@ -6,29 +6,12 @@ aliases: ['/docs/dev/sql-optimization-concepts/','/docs/dev/reference/performanc
 
 # SQL Optimization Process
 
-In TiDB, the process of SQL optimization consists of two phases: logical optimization and physical optimization. This document describes the logical and physical optimization to help you understand the whole process.
+In TiDB, the process from inputting a query to getting the execution result according to the final execution plan is illustrated as follows:
 
-## Logical optimization
+![SQL Optimization Process](/media/sql-optimization.png)
 
-Based on rules, logical optimization applies some optimization rules to the input logical execution plan in order, to make the whole logical execution plan better. The optimization rules include:
+After parsing the original query text by `parser` and some simple validity checks, TiDB first makes some logically equivalent changes to the query. For detailed changes, see [SQL Logical Optimization](/sql-logical-optimization.md).
 
-- Column pruning
-- Eliminate projection
-- Decorrelate correlated subqueries
-- [Eliminate Max/Min](/max-min-eliminate.md)
-- Push down predicates
-- Partition pruning
-- Push down TopN and Limit
-- [Join Reorder](/join-reorder.md)
+Through these equivalent changes, this query becomes easier to handle in the logical execution plan. After the equivalent change is done, TiDB obtains a query plan structure equivalent to the original query, and then obtains a final execution plan based on the data distribution and the specific execution cost of an operator. For details, see [SQL Physical Optimization](/sql-physical-optimization.md).
 
-## Physical optimization
-
-Based on cost, physical optimization makes the physical execution plan for the logical execution plan generated in the previous phase.
-
-In this phase, the optimizer selects the specific physical implementation for each operator in the logical execution plan. Different physical implementations of logical operators differ in time complexity, resource consumption, physical properties, and so on. During this process, the optimizer determines the cost of different physical implementations according to data statistics, and selects the physical execution plan with the minimum whole cost.
-
-The logical execution plan is a tree structure and each node corresponds to a logical operator in SQL. Similarly, the physical execution plan is also a tree structure, and each node corresponds to a physical operator in SQL.
-
-The logical operator only describes the function of an operator, while the physical operator describes the concrete algorithm that implements this function. A single logical operator might have multiple physical operator implementations. For example, to implement `LogicalAggregate`, you can use either `HashAggregate` the of the hash algorithm, or `StreamAggregate` of the stream type.
-
-Different physical operators have different physical properties, and have different requirements on the physical properties of their subnodes. The physical properties include the data's order, distribution, and so on. Currently, only the data order is considered in TiDB.
+At the same time, when TiDB executes the [`PREPARE`](/sql-statements/sql-statement-prepare.md) statement, you can choose to enable caching to reduce the cost of generating the execution plan in TiDB. For details, see [Execution Plan Cache](/sql-prepare-plan-cache.md).

sql-physical-optimization.md

@@ -0,0 +1,14 @@
+---
+title: SQL Physical Optimization
+---
+
+# SQL Physical Optimization
+
+Physical optimization is cost-based optimization, which makes a physical execution plan for the logical execution plan generated in the previous stage. In this stage, the optimizer selects a specific physical implementation for each operator in the logical execution plan. Different physical implementations of logical operators have different time complexity, resource consumption and physical properties. In this process, the optimizer determines the cost of different physical implementations based on the statistics of the data, and selects the physical execution plan with the smallest overall cost.
+
+[Understand the Query Execution Plan](/query-execution-plan.md) has introduced some physical operators. This chapter focuses on the following aspects:
+
+- In [Index Selection](/choose-index.md), you will learn how to select the optimal index to access tables when TiDB has multiple indexes on a table.
+- In [Introduction to Statistics](/statistics.md), you will learn what statistics TiDB collects to obtain the data distribution of a table.
+- [Wrong Index Solution](/wrong-index-solution.md) introduces how to use the right index when you find the index is selected wrongly.
+- [Distinct Optimization](/agg-distinct-optimization.md) introduces an optimization related to the `DISTINCT` keyword during physical optimization. In this section, you will learn its advantages and disadvantages and how to use it.

sql-statements/sql-statement-add-index.md

@@ -109,6 +109,8 @@ mysql> EXPLAIN SELECT * FROM t1 WHERE c1 = 3;
 
 ## See also
 
+* [Index Selection](/choose-index.md)
+* [Wrong Index Solution](/wrong-index-solution.md)
 * [CREATE INDEX](/sql-statements/sql-statement-create-index.md)
 * [DROP INDEX](/sql-statements/sql-statement-drop-index.md)
 * [RENAME INDEX](/sql-statements/sql-statement-rename-index.md)

sql-statements/sql-statement-create-index.md

@@ -172,6 +172,8 @@ The global variables associated with the `CREATE INDEX` statement are `tidb_ddl_
 
 ## See also
 
+* [Index Selection](/choose-index.md)
+* [Wrong Index Solution](/wrong-index-solution.md)
 * [ADD INDEX](/sql-statements/sql-statement-add-index.md)
 * [DROP INDEX](/sql-statements/sql-statement-drop-index.md)
 * [RENAME INDEX](/sql-statements/sql-statement-rename-index.md)

sql-tuning-overview.md

@@ -0,0 +1,11 @@
+---
+title: SQL Tuning Overview
+---
+
+# SQL Tuning Overview
+
+The previous "Troubleshoot" chapter describes some ways to locate some queries that affect the cluster, and that if some queries' execution time does not meet expectations, you need to analyze the execution result to find the cause. In this chapter, the following sections introduce how to tune a specific query:
+
+- In the first section, [Understand the Query Execution Plan](/query-execution-plan.md) introduces how to use the `EXPLAIN` and `EXPLAIN ANALYZE` statements to understand how TiDB executes a query.
+- In the second section, [SQL Optimization Process](/sql-optimization-concepts.md) introduces the optimizations used internally by TiDB, which involves some equivalent SQL conversions and the selection of physical plans. This section helps you understand how TiDB generates the final execution plan.
+- In the third section, [Control Execution Plan](/control-execution-plan.md) introduces the ways to control the generation of the execution plan, which improves the execution speed of the query and reduces its impact on the overall performance of the cluster or online business.

ticdc/troubleshoot-ticdc.md

@@ -35,7 +35,7 @@ A replication task might be interrupted in the following known scenarios:
     - In this scenario, TiCDC saves the task information. Because TiCDC has set the service GC safepoint in PD, the data after the task checkpoint is not cleaned by TiKV GC within the valid period of `gc-ttl`.
     - Handling procedures:
         1. Query the status information of the replication task using the `cdc cli changefeed query` command and record the value of `checkpoint-ts`.
-        2. Use the new task configuration file and add the `ignore-txn-commit-ts` parameter to skip the transaction corresponding to the specified `commit-ts`.
+        2. Use the new task configuration file and add the `ignore-txn-start-ts` parameter to skip the transaction corresponding to the specified `start-ts`.
         3. Stop the old replication task via HTTP API. Execute `cdc cli changefeed create` to create a new task and specify the new task configuration file. Specify `checkpoint-ts` recorded in step 1 as the `start-ts` and start a new task to resume the replication.
 
 ## `gc-ttl` and file sorting