sql: align multiple PRs from docs-cn (pingcap#6930)

Author: TomShawn

best-practices/tidb-best-practices.md

@@ -160,14 +160,14 @@ As mentioned before, TiDB limits the size of a single transaction in the Key-Val
 
 It is recommended to split statements into batches or add a limit to the statements, whether they are `INSERT`, `UPDATE` or `DELETE` statements.
 
-When deleting a large amount of data, it is recommended to use `Delete * from t where xx limit 5000;`. It deletes through the loop and use `Affected Rows == 0` as a condition to end the loop.
+When deleting a large amount of data, it is recommended to use `Delete from t where xx limit 5000;`. It deletes through the loop and use `Affected Rows == 0` as a condition to end the loop.
 
 If the amount of data that needs to be deleted at a time is large, this loop method gets slower and slower because each deletion traverses backward. After deleting the previous data, lots of deleted flags remain for a short period (then all is cleared by Garbage Collection) and affect the following `DELETE` statement. If possible, it is recommended to refine the `WHERE` condition. Assume that you need to delete all data on `2017-05-26`, you can use the following statements:
 
 ```sql
 for i from 0 to 23:
     while affected_rows > 0:
-        delete * from t where insert_time >= i:00:00 and insert_time < (i+1):00:00 limit 5000;
+        delete from t where insert_time >= i:00:00 and insert_time < (i+1):00:00 limit 5000;
         affected_rows = select affected_rows()
 ```
 

faq/migration-tidb-faq.md

@@ -174,7 +174,7 @@ Deleting a large amount of data leaves a lot of useless keys, affecting the quer
 
 ### What is the most efficient way of deleting data?
 
-When deleting a large amount of data, it is recommended to use `Delete * from t where xx limit 5000;`. It deletes through the loop and uses `Affected Rows == 0` as a condition to end the loop, so as not to exceed the limit of transaction size. With the prerequisite of meeting business filtering logic, it is recommended to add a strong filter index column or directly use the primary key to select the range, such as `id >= 5000*n+m and id < 5000*(n+1)+m`.
+When deleting a large amount of data, it is recommended to use `Delete from t where xx limit 5000;`. It deletes through the loop and uses `Affected Rows == 0` as a condition to end the loop, so as not to exceed the limit of transaction size. With the prerequisite of meeting business filtering logic, it is recommended to add a strong filter index column or directly use the primary key to select the range, such as `id >= 5000*n+m and id < 5000*(n+1)+m`.
 
 If the amount of data that needs to be deleted at a time is very large, this loop method will get slower and slower because each deletion traverses backward. After deleting the previous data, lots of deleted flags remain for a short period (then all will be processed by Garbage Collection) and influence the following Delete statement. If possible, it is recommended to refine the Where condition. See [details in TiDB Best Practices](https://pingcap.com/blog/2017-07-24-tidbbestpractice/#write).
 

information-schema/information-schema-statistics.md

@@ -51,7 +51,7 @@ Fields in the `STATISTICS` table are described as follows:
 * `SEQ_IN_INDEX`: The column number in the index, starting from `1`.
 * `COLUMN_NAME`: The column name. See the description of the `Expression` column.
 * `COLLATION`: The sorting method of the columns in the index. The value can be `A` (ascending order), `D` (descending order) or `NULL` (unsorted).
-* `CARDINALITY`: The estimated number of unique values ​​in the index. To update this value, execute `ANALYZE TABLE`.
+* `CARDINALITY`: TiDB does not use this field. The field value is always `0`.
 * `SUB_PART`: The prefix of the index. If only part of the prefix of the column is indexed, the value is the number of indexed characters; if the entire column is indexed, the value is `NULL`.
 * `PACKED`: TiDB does not use this field. This value is always `NULL`.
 * `NULLABLE`: If the column might contain a `NULL` value, the value is `YES`; if not, the value is `''`.

releases/release-5.0.0-rc.md

@@ -138,7 +138,7 @@ Related issue: [#18005](https://github.com/pingcap/tidb/issues/18005)
 
 ### Other performance optimizations
 
-+ Improve the execution performance of `delete * from table where id <?` statement. Its P99 performance improves by four times. [#18028](https://github.com/pingcap/tidb/issues/18028)
++ Improve the execution performance of `delete from table where id <?` statement. Its P99 performance improves by four times. [#18028](https://github.com/pingcap/tidb/issues/18028)
 + TiFlash supports concurrently reading and writing data in multiple local disks to improve performance.
 
 ## High availability and disaster recovery

releases/release-5.0.0.md

@@ -261,11 +261,11 @@ In 5.0 GA, the Coprocessor cache feature is enabled by default. After this featu
 
 To disable the Coprocessor cache feature, you can modify the `capacity-mb` configuration item of `tikv-client.copr-cache` to `0.0`.
 
-### Improve the execution performance of `delete * from table where id <? Limit ?` statement
+### Improve the execution performance of `delete from table where id <? Limit ?` statement
 
 [#18028](https://github.com/pingcap/tidb/issues/18028)
 
-The p99 performance of the `delete * from table where id <? limit ?` statement is improved by 4 times.
+The p99 performance of the `delete from table where id <? limit ?` statement is improved by 4 times.
 
 ### Optimize load base split strategy to solve the performance problem that data cannot be split in some small table hotspot read scenarios
 

sql-plan-management.md

@@ -86,10 +86,30 @@ If you do not specify the scope when creating an execution plan binding, the def
 
 ```sql
 select * from t where a >    1
--- Normalized:
+-- After normalization, the above statement is as follows:
 select * from test . t where a > ?
 ```
 
+> **Note:**
+>
+> Multiple constants joined by commas `,` are normalized as `...` instead of `?`.
+>
+> For example:
+>
+> ```sql
+> select * from t limit 10
+> select * from t limit 10, 20
+> select * from t where a in (1)
+> select * from t where a in (1,2,3)
+> -- After normalization, the above statements are as follows:
+> select * from test . t limit ?
+> select * from test . t limit ...
+> select * from test . t where a in ( ? )
+> select * from test . t where a in ( ... )
+> ```
+>
+> When bindings are created, TiDB treats SQL statements that contain a single constant and SQL statements that contain multiple constants joined by commas differently. Therefore, you need to create bindings for the two SQL types separately.
+
 When a SQL statement has bound execution plans in both GLOBAL and SESSION scopes, because the optimizer ignores the bound execution plan in the GLOBAL scope when it encounters the SESSION binding, the bound execution plan of this statement in the SESSION scope shields the execution plan in the GLOBAL scope.
 
 For example:

sql-statements/sql-statement-show-indexes.md

@@ -72,7 +72,7 @@ mysql> SHOW KEYS FROM t1;
 
 ## MySQL compatibility
 
-This statement is understood to be fully compatible with MySQL. Any compatibility differences should be [reported via an issue](https://github.com/pingcap/tidb/issues/new/choose) on GitHub.
+The `Cardinality` column in MySQL shows the number of different values on the index. In TiDB, the `Cardinality` column always shows `0`.
 
 ## See also
 

sql-statements/sql-statement-show-processlist.md

@@ -22,13 +22,12 @@ This statement lists the current sessions connected to the same TiDB server. The
 
 ```sql
 mysql> SHOW PROCESSLIST;
-+------+------+-----------+------+---------+------+-------+------------------+
-| Id   | User | Host      | db   | Command | Time | State | Info             |
-+------+------+-----------+------+---------+------+-------+------------------+
-|    1 | root | 127.0.0.1 | test | Query   |    0 | 2     | SHOW PROCESSLIST |
-|    2 | root | 127.0.0.1 |      | Sleep   |    4 | 2     |                  |
-+------+------+-----------+------+---------+------+-------+------------------+
-2 rows in set (0.00 sec)
++------+------+-----------------+------+---------+------+------------+------------------+
+| Id   | User | Host            | db   | Command | Time | State      | Info             |
++------+------+-----------------+------+---------+------+------------+------------------+
+|    5 | root | 127.0.0.1:45970 | test | Query   |    0 | autocommit | SHOW PROCESSLIST |
++------+------+-----------------+------+---------+------+------------+------------------+
+1 rows in set (0.00 sec)
 ```
 
 ## MySQL compatibility