*: fix code block format, update wording and format (pingcap#820)

Via: pingcap/docs-cn#1047

sql/tidb-specific.md

@@ -294,9 +294,9 @@ set @@global.tidb_distsql_scan_concurrency = 10
 TiDB supports optimizer hints, based on the comment-like syntax introduced in MySQL 5.7. i.e. `/*+ TIDB_XX(t1, t2) */`. Use of optimizer hints is recommended in cases where the TiDB optimizer selects a less optimal query plan.
 
 > **Note:** MySQL command-line clients earlier than 5.7.7 strip optimizer hints by default. If you want to use the `Hint` syntax in these earlier versions, add the `--comments` option when starting the client. For example: `mysql -h 127.0.0.1 -P 4000 -uroot --comments`.
- 
+
 ### TIDB_SMJ(t1, t2)
- 
+
 ```sql
 SELECT /*+ TIDB_SMJ(t1, t2) */ * from t1, t2 where t1.id = t2.id
 ```

v1.0/sql/tidb-specific.md

@@ -8,47 +8,61 @@ category: user guide
 On the basis of MySQL variables and syntaxes, TiDB has defined some specific system variables and syntaxes to optimize performance.
 
 ## System variable
+
 Variables can be set with the `SET` statement, for example:
 
-```set @@tidb_distsql_scan_concurrency = 10 ```
+```sql
+set @@tidb_distsql_scan_concurrency = 10
+```
 
 If you need to set the global variable, run:
 
-```set @@global.tidb_distsql_scan_concurrency = 10 ```
-
+```sql
+set @@global.tidb_distsql_scan_concurrency = 10
+```
+
 ### tidb_distsql_scan_concurrency
+
 Scope: SESSION | GLOBAL
 Default value: 10
 This variable is used to set the concurrency of the `scan` operation. Use a bigger value in OLAP scenarios, and a smaller value in OLTP scenarios. For OLAP scenarios, the maximum value cannot exceed the number of CPU cores of all the TiKV nodes.
- 
+
 ### tidb_index_lookup_size
+
 Scope: SESSION | GLOBAL
 Default value: 20000
 This variable is used to set the batch size of index lookup operation. Use a bigger value in OLAP scenarios, and a smaller value in OLTP scenarios.
- 
+
 ### tidb_index_lookup_concurrency
+
 Scope: SESSION | GLOBAL
 Default value: 4
 This variable is used to set the concurrency of the `index lookup` operation. Use a bigger value in OLAP scenarios, and a smaller value in OLTP scenarios.
- 
+
 ### tidb_index_serial_scan_concurrency
+
 Scope: SESSION | GLOBAL
 Default value: 1
 This variable is used to set the concurrency of the `serial scan` operation. Use a bigger value in OLAP scenarios, and a smaller value in OLTP scenarios.
- 
+
 ## Optimizer hint
+
 On the basis of MySQL’s `Optimizer Hint` Syntax, TiDB adds some proprietary `Hint` syntaxes. When using the `Hint` syntax, the TiDB optimizer will try to use the specific algorithm, which performs better than the default algorithm in some scenarios.
- 
+
 The `Hint` syntax is included in comments like `/*+ xxx */`, and in MySQL client versions earlier than 5.7.7, the comment is removed by default. If you want to use the `Hint` syntax in these earlier versions, add the `--comments` option when starting the client. For example: `mysql -h 127.0.0.1 -P 4000 -uroot --comments`.
- 
+
 ### TIDB_SMJ(t1, t2)
-
-```SELECT /*+ TIDB_SMJ(t1, t2) */ * from t1，t2 where t1.id = t2.id```
+
+```sql
+SELECT /*+ TIDB_SMJ(t1, t2) */ * from t1，t2 where t1.id = t2.id
+```
 
 This variable is used to remind the optimizer to use the `Sort Merge Join` algorithm. This algorithm takes up less memory, but takes longer to execute. It is recommended if the data size is too large, or there’s insufficient system memory.
 
 ### TIDB_INLJ(t1, t2)
-
-```SELECT /*+ TIDB_INLJ(t1, t2) */ * from t1，t2 where t1.id = t2.id```
+
+```sql
+SELECT /*+ TIDB_INLJ(t1, t2) */ * from t1，t2 where t1.id = t2.id
+```
 
 This variable is used to remind the optimizer to use the `Index Nested Loop Join` algorithm. In some scenarios, this algorithm runs faster and takes up fewer system resources, but may be slower and takes up more system resources in some other scenarios. You can try to use this algorithm in scenarios where the result-set is less than 10,000 rows after the outer table is filtered by the WHERE condition. The parameter in `TIDB_INLJ()` is the candidate table for the driving table (external table) when generating the query plan. That means, `TIDB_INLJ (t1)` will only consider using t1 as the driving table to create a query plan.

v2.0/op-guide/backup-restore.md

@@ -73,6 +73,7 @@ Use `mydumper` to backup data from TiDB.
 ```bash
 ./bin/mydumper -h 127.0.0.1 -P 4000 -u root -t 16 -F 64 -B test -T t1,t2 --skip-tz-utc -o ./var/test
 ```
+
 In this command,
 
 - `-B test`: means the data is exported from the `test` database.

v2.0/op-guide/migration.md

@@ -19,6 +19,7 @@ Use the `mydumper` tool to export data from MySQL by using the following command
 ```bash
 ./bin/mydumper -h 127.0.0.1 -P 3306 -u root -t 16 -F 64 -B test -T t1,t2 --skip-tz-utc -o ./var/test
 ```
+
 In this command,
 
 - `-B test`: means the data is exported from the `test` database.
@@ -116,11 +117,12 @@ tar -xzf tidb-enterprise-tools-latest-linux-amd64.tar.gz
 cd tidb-enterprise-tools-latest-linux-amd64
 ```
 
-Assuming the data from `t1` and `t2` is already imported to TiDB using `mydumper`/`loader`. Now we hope that any updates to these two tables are synchronised to TiDB in real time.
+Assuming the data from `t1` and `t2` is already imported to TiDB using `mydumper`/`loader`. Now we hope that any updates to these two tables are synchronized to TiDB in real time.
 
-### Obtain the position to synchronise
+### Obtain the position to synchronize
 
 The data exported from MySQL contains a metadata file which includes the position information. Take the following metadata information as an example:
+
 ```
 Started dump at: 2017-04-28 10:48:10
 SHOW MASTER STATUS:
@@ -129,8 +131,8 @@ SHOW MASTER STATUS:
     GTID:
 
 Finished dump at: 2017-04-28 10:48:11
-
 ```
+
 The position information (`Pos: 930143241`) needs to be stored in the `syncer.meta` file for `syncer` to synchronize:
 
 ```bash
@@ -139,7 +141,7 @@ binlog-name = "mysql-bin.000003"
 binlog-pos = 930143241
 ```
 
-> **Note:** The `syncer.meta` file only needs to be configured once when it is first used. The position will be automatically updated when binlog is synchronised.
+> **Note:** The `syncer.meta` file only needs to be configured once when it is first used. The position will be automatically updated when binlog is synchronized.
 
 ### Start `syncer`
 
@@ -160,25 +162,25 @@ status-addr = ":10081"
 
 skip-sqls = ["ALTER USER", "CREATE USER"]
 
-# Support whitelist filter. You can specify the database and table to be synchronised. For example:
-# Synchronise all the tables of db1 and db2:
+# Support whitelist filter. You can specify the database and table to be synchronized. For example:
+# Synchronize all the tables of db1 and db2:
 replicate-do-db = ["db1","db2"]
 
-# Synchronise db1.table1.
+# Synchronize db1.table1.
 [[replicate-do-table]]
 db-name ="db1"
 tbl-name = "table1"
 
-# Synchronise db3.table2.
+# Synchronize db3.table2.
 [[replicate-do-table]]
 db-name ="db3"
 tbl-name = "table2"
 
 # Support regular expressions. Start with '~'  to use regular expressions.
-# To synchronise all the databases that start with `test`:
+# To synchronize all the databases that start with `test`:
 replicate-do-db = ["~^test.*"]
 
-# The sharding synchronising rules support wildcharacter.
+# The sharding synchronizing rules support wildcharacter.
 # 1. The asterisk character (*, also called "star") matches zero or more characters,
 #    for example, "doc*" matches "doc" and "document" but not "dodo";
 #    asterisk character must be in the end of the wildcard word,
@@ -241,7 +243,7 @@ mysql> select * from t1;
 +----+------+
 ```
 
-`syncer` outputs the current synchronised data statistics every 30 seconds:
+`syncer` outputs the current synchronized data statistics every 30 seconds:
 
 ```bash
 2017/06/08 01:18:51 syncer.go:934: [info] [syncer]total events = 15, total tps = 130, recent tps = 4,
@@ -252,4 +254,4 @@ master-binlog = (ON.000001, 11992), master-binlog-gtid=53ea0ed1-9bf8-11e6-8bea-6
 syncer-binlog = (ON.000001, 2504), syncer-binlog-gtid = 53ea0ed1-9bf8-11e6-8bea-64006a897c73:1-35
 ```
 
-You can see that by using `syncer`, the updates in MySQL are automatically synchronised in TiDB.
+You can see that by using `syncer`, the updates in MySQL are automatically synchronized in TiDB.

v2.0/sql/aggregate-group-by-functions.md

@@ -84,6 +84,7 @@ group by id, floor(value/100);
 TiDB extends standard SQL to permit noncolumn expressions in `GROUP BY` clauses and considers the preceding statement valid.
 
 Standard SQL also does not permit aliases in `GROUP BY` clauses. TiDB extends standard SQL to permit aliases, so another way to write the query is as follows:
+
 ```sql
 select id, floor(value/100) as val
 from tbl_name

v2.0/sql/tidb-specific.md

@@ -12,13 +12,13 @@ On the basis of MySQL variables and syntaxes, TiDB has defined some specific sys
 
 Variables can be set with the `SET` statement, for example:
 
-```
+```sql
 set @@tidb_distsql_scan_concurrency = 10
 ```
 
 If you need to set the global variable, run:
 
-```
+```sql
 set @@global.tidb_distsql_scan_concurrency = 10
 ```
 
@@ -285,23 +285,29 @@ set @@global.tidb_distsql_scan_concurrency = 10
 ## Optimizer Hint
 
 On the basis of MySQL’s `Optimizer Hint` Syntax, TiDB adds some proprietary `Hint` syntaxes. When using the `Hint` syntax, the TiDB optimizer will try to use the specific algorithm, which performs better than the default algorithm in some scenarios.
- 
+
 The `Hint` syntax is included in comments like `/*+ xxx */`, and in MySQL client versions earlier than 5.7.7, the comment is removed by default. If you want to use the `Hint` syntax in these earlier versions, add the `--comments` option when starting the client. For example: `mysql -h 127.0.0.1 -P 4000 -uroot --comments`.
- 
+
 ### TIDB_SMJ(t1, t2)
-
-```SELECT /*+ TIDB_SMJ(t1, t2) */ * from t1, t2 where t1.id = t2.id```
+
+```sql
+SELECT /*+ TIDB_SMJ(t1, t2) */ * from t1, t2 where t1.id = t2.id
+```
 
 This variable is used to remind the optimizer to use the `Sort Merge Join` algorithm. This algorithm takes up less memory, but takes longer to execute. It is recommended if the data size is too large, or there’s insufficient system memory.
 
 ### TIDB_INLJ(t1, t2)
-
-```SELECT /*+ TIDB_INLJ(t1, t2) */ * from t1, t2 where t1.id = t2.id```
+
+```sql
+SELECT /*+ TIDB_INLJ(t1, t2) */ * from t1, t2 where t1.id = t2.id
+```
 
 This variable is used to remind the optimizer to use the `Index Nested Loop Join` algorithm. In some scenarios, this algorithm runs faster and takes up fewer system resources, but may be slower and takes up more system resources in some other scenarios. You can try to use this algorithm in scenarios where the result-set is less than 10,000 rows after the outer table is filtered by the WHERE condition. The parameter in `TIDB_INLJ()` is the candidate table for the driving table (external table) when generating the query plan. That means, `TIDB_INLJ (t1)` will only consider using t1 as the driving table to create a query plan.
 
 ### TIDB_HJ(t1, t2)
 
-```SELECT /*+ TIDB_HJ(t1, t2) */ * from t1, t2 where t1.id = t2.id```
+```sql
+SELECT /*+ TIDB_HJ(t1, t2) */ * from t1, t2 where t1.id = t2.id
+```
 
 This variable is used to remind the optimizer to use the `Hash Join` algorithm. This algorithm executes threads concurrently. It runs faster but takes up more memory.