Capitalize sql keywords in several files

why: issue: pingcap#699

auto-random.md

@@ -19,34 +19,34 @@ Take the following created table as an example:
 {{< copyable "sql" >}}
 
 ```sql
-create table t (a bigint primary key auto_increment, b varchar(255))
+CREATE TABLE t (a bigint PRIMARY KEY AUTO_INCREMENT, b varchar(255))
 ```
 
 On this `t` table, you execute a large number of `INSERT` statements that do not specify the values of the primary key as below:
 
 {{< copyable "sql" >}}
 
 ```sql
-insert into t(b) values ('a'), ('b'), ('c')
+INSERT INTO t(b) VALUES ('a'), ('b'), ('c')
 ```
 
 In the above statement, values of the primary key (column `a`) are not specified, so TiDB uses the continuous auto-increment row values as the row IDs, which might cause write hotspot in a single TiKV node and affect the performance. To avoid such write hotspot, you can specify the `AUTO_RANDOM` attribute rather than the `AUTO_INCREMENT` attribute for the column `a` when you create the table. See the follow examples:
 
 {{< copyable "sql" >}}
 
 ```sql
-create table t (a bigint primary key auto_random, b varchar(255))
+CREATE TABLE t (a bigint PRIMARY KEY AUTO_RANDOM, b varchar(255))
 ```
 
 or
 
 {{< copyable "sql" >}}
 
 ```sql
-create table t (a bigint auto_random, b varchar(255), primary key (a))
+CREATE TABLE t (a bigint AUTO_RANDOM, b varchar(255), PRIMARY KEY (a))
 ```
 
-Then execute the `INSERT` statement such as `INSERT INTO t(b) values...`. Now the results will be as follows:
+Then execute the `INSERT` statement such as `INSERT INTO t(b) VALUES...`. Now the results will be as follows:
 
 + Implicitly allocating values: If the `INSERT` statement does not specify the values of the integer primary key column (column `a`) or specify the value as `NULL`, TiDB automatically allocates values to this column. These values are not necessarily auto-increment or continuous but are unique, which avoids the hotspot problem caused by continuous row IDs.
 + Explicitly inserting values: If the `INSERT` statement explicitly specifies the values of the integer primary key column, TiDB saves these values, which works similarly to the `AUTO_INCREMENT` attribute. Note that if you do not set `NO_AUTO_VALUE_ON_ZERO` in the `@@sql_mode` system variable, TiDB will automatically allocate values to this column even if you explicitly specify the value of the integer primary key column as `0`.
@@ -64,7 +64,7 @@ To use different number of shard bits, append a pair of parentheses to `AUTO_RAN
 {{< copyable "sql" >}}
 
 ```sql
-create table t (a bigint primary key auto_random(3), b varchar(255))
+CREATE TABLE t (a bigint PRIMARY KEY AUTO_RANDOM(3), b varchar(255))
 ```
 
 In the above `CREATE TABLE` statement, `3` shard bits are specified. The range of the number of shard bits is `[1, field_max_bits)`. `field_max_bits` is the length of bits occupied by the primary key column.
@@ -74,7 +74,7 @@ After creating the table, use the `SHOW WARNINGS` statement to see the maximum n
 {{< copyable "sql" >}}
 
 ```sql
-show warnings
+SHOW WARNINGS
 ```
 
 ```sql
@@ -91,14 +91,14 @@ show warnings
 
 In addition, to view the shard bit number of the table with the `AUTO_RANDOM` attribute, you can see the value of the `PK_AUTO_RANDOM_BITS=x` mode in the `TIDB_ROW_ID_SHARDING_INFO` column in the `information_schema.tables` system table. `x` is the number of shard bits.
 
-Values allocated to the `AUTO_RANDOM` column affect `last_insert_id()`. You can use `select last_insert_id ()` to get the ID that TiDB last implicitly allocates. For example:
+Values allocated to the `AUTO_RANDOM` column affect `last_insert_id()`. You can use `SELECT last_insert_id ()` to get the ID that TiDB last implicitly allocates. For example:
 
 {{< copyable "sql" >}}
 
 ```sql
-insert into t (b) values ("b")
-select * from t;
-select last_insert_id()
+INSERT INTO t (b) VALUES ("b")
+SELECT * FROM t;
+SELECT last_insert_id()
 ```
 
 You might see the following result:
@@ -123,18 +123,18 @@ TiDB supports parsing the version comment syntax. See the following example:
 {{< copyable "sql" >}}
 
 ```sql
-create table t (a bigint primary key /*T![auto_rand] auto_random */)
+CREATE TABLE t (a bigint PRIMARY KEY /*T![auto_rand] auto_random */)
 ```
 
 {{< copyable "sql" >}}
 
 ```sql
-create table t (a bigint primary key auto_random)
+CREATE TABLE t (a bigint PRIMARY KEY AUTO_RANDOM)
 ```
 
 The above two statements have the same meaning.
 
-In the result of `show create table`, the `AUTO_RANDOM` attribute is commented out. This comment includes an attribute identifier (for example, `/*T![auto_rand] auto_random */`). Here `auto_rand` represents the `AUTO_RANDOM` attribute. Only the version of TiDB that implements the feature corresponding to this identifier can parse the SQL statement fragment properly.
+In the result of `SHOW CREATE TABLE`, the `AUTO_RANDOM` attribute is commented out. This comment includes an attribute identifier (for example, `/*T![auto_rand] auto_random */`). Here `auto_rand` represents the `AUTO_RANDOM` attribute. Only the version of TiDB that implements the feature corresponding to this identifier can parse the SQL statement fragment properly.
 
 This attribute supports forward compatibility, namely, downgrade compatibility. TiDB of earlier versions that do not implement this feature ignore the `AUTO_RANDOM` attribute of a table (with the above comment) and can also use the table with the attribute.
 

backup-and-restore-using-dumpling-lightning.md

@@ -70,15 +70,15 @@ The steps to manually modify the GC time are as follows:
     {{< copyable "sql" >}}
 
     ```sql
-    update mysql.tidb set VARIABLE_VALUE = '720h' where VARIABLE_NAME = 'tikv_gc_life_time';
+    UPDATE mysql.tidb SET VARIABLE_VALUE = '720h' WHERE VARIABLE_NAME = 'tikv_gc_life_time';
     ```
 
 2. After executing the `dumpling` command, restore the GC value of the TiDB cluster to the initial value in step 1:
 
     {{< copyable "sql" >}}
 
     ```sql
-    update mysql.tidb set VARIABLE_VALUE = '10m' where VARIABLE_NAME = 'tikv_gc_life_time';
+    UPDATE mysql.tidb SET VARIABLE_VALUE = '10m' WHERE VARIABLE_NAME = 'tikv_gc_life_time';
     ```
 
 ## Restore data into TiDB

backup-and-restore-using-mydumper-lightning.md

@@ -80,15 +80,15 @@ Then execute two more commands:
     {{< copyable "sql" >}}
 
     ```sql
-    update mysql.tidb set VARIABLE_VALUE = '720h' where VARIABLE_NAME = 'tikv_gc_life_time';
+    UPDATE mysql.tidb SET VARIABLE_VALUE = '720h' WHERE VARIABLE_NAME = 'tikv_gc_life_time';
     ```
 
 2. After running the `mydumper` command, adjust GC value of the TiDB cluster to its original value in step 1.
 
     {{< copyable "sql" >}}
 
     ```sql
-    update mysql.tidb set VARIABLE_VALUE = '10m' where VARIABLE_NAME = 'tikv_gc_life_time';
+    UPDATE mysql.tidb SET VARIABLE_VALUE = '10m' WHERE VARIABLE_NAME = 'tikv_gc_life_time';
     ```
 
 ## Restore data into TiDB

basic-sql-operations.md

@@ -43,7 +43,7 @@ To use the database named `mysql`, use the following statement:
 {{< copyable "sql" >}}
 
 ```sql
-use mysql;
+USE mysql;
 ```
 
 To show all the tables in a database, use the `SHOW TABLES` statement:
@@ -157,7 +157,7 @@ To show all the indexes in a table, use the `SHOW INDEX` statement:
 {{< copyable "sql" >}}
 
 ```sql
-SHOW INDEX from person;
+SHOW INDEX FROM person;
 ```
 
 To delete an index, use the `DROP INDEX` or `ALTER TABLE` statement. `DROP INDEX` can be nested in `ALTER TABLE`:

blocklist-control-plan.md

@@ -42,7 +42,7 @@ You can use the blocklist of optimization rules to disable some of them if some
     {{< copyable "sql" >}}
 
     ```sql
-    insert into mysql.opt_rule_blacklist values("join_reorder"), ("topn_push_down");
+    INSERT INTO mysql.opt_rule_blacklist VALUES("join_reorder"), ("topn_push_down");
     ```
 
     Executing the following SQL statement can make the above operation take effect immediately. The effective range includes all old connections of the corresponding TiDB server:
@@ -62,7 +62,7 @@ You can use the blocklist of optimization rules to disable some of them if some
     {{< copyable "sql" >}}
 
     ```sql
-    delete from mysql.opt_rule_blacklist where name in ("join_reorder", "topn_push_down");
+    DELETE FROM mysql.opt_rule_blacklist WHERE name IN ("join_reorder", "topn_push_down");
     ```
 
     {{< copyable "sql" >}}
@@ -95,7 +95,7 @@ The schema of `mysql.expr_pushdown_blacklist` is shown as follows:
 {{< copyable "sql" >}}
 
 ```sql
-desc mysql.expr_pushdown_blacklist;
+DESC mysql.expr_pushdown_blacklist;
 ```
 
 ```sql
@@ -153,7 +153,7 @@ To judge whether the blocklist takes effect, observe the results of `EXPLAIN` (S
     {{< copyable "sql" >}}
 
     ```sql
-    explain select * from t where a < 2 and a > 2;
+    explain SELECT * FROM t WHERE a < 2 AND a > 2;
     ```
 
     ```sql
@@ -172,7 +172,7 @@ To judge whether the blocklist takes effect, observe the results of `EXPLAIN` (S
     {{< copyable "sql" >}}
 
     ```sql
-    insert into mysql.expr_pushdown_blacklist values('<','tikv',''), ('>','tikv','');
+    INSERT INTO mysql.expr_pushdown_blacklist VALUES('<','tikv',''), ('>','tikv','');
     ```
 
     ```sql
@@ -195,7 +195,7 @@ To judge whether the blocklist takes effect, observe the results of `EXPLAIN` (S
     {{< copyable "sql" >}}
 
     ```sql
-    explain select * from t where a < 2 and a > 2;
+    explain SELECT * FROM t WHERE a < 2 and a > 2;
     ```
 
     ```sql
@@ -214,7 +214,7 @@ To judge whether the blocklist takes effect, observe the results of `EXPLAIN` (S
     {{< copyable "sql" >}}
 
     ```sql
-    delete from mysql.expr_pushdown_blacklist where name = '>';
+    DELETE FROM mysql.expr_pushdown_blacklist WHERE name = '>';
     ```
 
     ```sql
@@ -236,7 +236,7 @@ To judge whether the blocklist takes effect, observe the results of `EXPLAIN` (S
     {{< copyable "sql" >}}
 
     ```sql
-    explain select * from t where a < 2 and a > 2;
+    explain SELECT * FROM t WHERE a < 2 AND a > 2;
     ```
 
     ```sql

character-set-and-collation.md

@@ -173,7 +173,7 @@ Different databases can use different character sets and collations. Use the `ch
 {{< copyable "sql" >}}
 
 ```sql
-create schema test1 character set utf8mb4 COLLATE uft8mb4_general_ci;
+CREATE SCHEMA test1 CHARACTER SET utf8mb4 COLLATE uft8mb4_general_ci;
 ```
 
 ```sql
@@ -183,7 +183,7 @@ Query OK, 0 rows affected (0.09 sec)
 {{< copyable "sql" >}}
 
 ```sql
-use test1;
+USE test1;
 ```
 
 ```sql
@@ -208,7 +208,7 @@ SELECT @@character_set_database, @@collation_database;
 {{< copyable "sql" >}}
 
 ```sql
-create schema test2 character set latin1 COLLATE latin1_bin;
+CREATE SCHEMA test2 CHARACTER SET latin1 COLLATE latin1_bin;
 ```
 
 ```sql
@@ -218,7 +218,7 @@ Query OK, 0 rows affected (0.09 sec)
 {{< copyable "sql" >}}
 
 ```sql
-use test2;
+USE test2;
 ```
 
 ```sql
@@ -387,13 +387,13 @@ Before v4.0, you can specify most of the MySQL collations in TiDB, and these col
 {{< copyable "sql" >}}
 
 ```sql
-create table t(a varchar(20) charset utf8mb4 collate utf8mb4_general_ci primary key);
+CREATE TABLE t(a varchar(20) charset utf8mb4 collate utf8mb4_general_ci PRIMARY KEY);
 Query OK, 0 rows affected
-insert into t values ('A');
+INSERT INTO t VALUES ('A');
 Query OK, 1 row affected
-insert into t values ('a');
+INSERT INTO t VALUES ('a');
 Query OK, 1 row affected # In TiDB, it is successfully executed. In MySQL, because utf8mb4_general_ci is case-insensitive, the `Duplicate entry 'a'` error is reported.
-insert into t1 values ('a ');
+INSERT INTO t1 VALUES ('a ');
 Query OK, 1 row affected # In TiDB, it is successfully executed. In MySQL, because comparison is performed after the spaces are filled in, the `Duplicate entry 'a '` error is returned.
 ```
 
@@ -404,7 +404,7 @@ In TiDB 4.0, a complete framework for collations is introduced. This new framewo
 {{< copyable "sql" >}}
 
 ```sql
-select VARIABLE_VALUE from mysql.tidb where VARIABLE_NAME='new_collation_enabled';
+SELECT VARIABLE_VALUE FROM mysql.tidb WHERE VARIABLE_NAME='new_collation_enabled';
 ```
 
 ```sql
@@ -423,13 +423,13 @@ When one of `utf8_general_ci`, `utf8mb4_general_ci`, `utf8_unicode_ci`, and `utf
 {{< copyable "sql" >}}
 
 ```sql
-create table t(a varchar(20) charset utf8mb4 collate utf8mb4_general_ci primary key);
+CREATE TABLE t(a varchar(20) charset utf8mb4 collate utf8mb4_general_ci PRIMARY KEY);
 Query OK, 0 rows affected (0.00 sec)
-insert into t values ('A');
+INSERT INTO t VALUES ('A');
 Query OK, 1 row affected (0.00 sec)
-insert into t values ('a');
+INSERT INTO t VALUES ('a');
 ERROR 1062 (23000): Duplicate entry 'a' for key 'PRIMARY' # TiDB is compatible with the case-insensitive collation of MySQL.
-insert into t values ('a ');
+INSERT INTO t VALUES ('a ');
 ERROR 1062 (23000): Duplicate entry 'a ' for key 'PRIMARY' # TiDB modifies the `PADDING` behavior to be compatible with MySQL.
 ```
 
@@ -465,7 +465,7 @@ TiDB supports using the `COLLATE` clause to specify the collation of an expressi
 {{< copyable "sql" >}}
 
 ```sql
-select 'a' = _utf8mb4 'A' collate utf8mb4_general_ci;
+SELECT 'a' = _utf8mb4 'A' collate utf8mb4_general_ci;
 ```
 
 ```sql