pingcap · ran-huang · Jun 15, 2020 · Jun 15, 2020
diff --git a/sql-statements/sql-statement-commit.md b/sql-statements/sql-statement-commit.md
@@ -36,7 +36,8 @@ Query OK, 0 rows affected (0.01 sec)
 ## MySQL compatibility
 
 * In MySQL, with the exception of Group Replication with multiple primaries, it is not typical that a `COMMIT` statement could result in an error. By contrast, TiDB uses optimistic concurrency control and conflicts may result in `COMMIT` returning an error.
-* Be default, `UNIQUE` and `PRIMARY KEY` constraint checks are deffered until statement commit. This behavior can be changed by setting `tidb_constraint_check_in_place=TRUE`.
+* Be default, `UNIQUE` and `PRIMARY KEY` constraint checks are deferred until statement commit. This behavior can be changed by setting `tidb_constraint_check_in_place=TRUE`.
+* TiDB only has syntactic support for `CompletionTypeWithinTransaction`. Closing the connection or continuing to open a new transaction after the transaction is committed is not supported.
 
 ## See also
 

diff --git a/sql-statements/sql-statement-execute.md b/sql-statements/sql-statement-execute.md
@@ -15,10 +15,6 @@ The `EXECUTE` statement provides an SQL interface to server-side prepared statem
 
 ![ExecuteStmt](/media/sqlgram/ExecuteStmt.png)
 
-**Identifier:**
-
-![Identifier](/media/sqlgram/Identifier.png)
-
 ## Examples
 
 ```sql

diff --git a/sql-statements/sql-statement-insert.md b/sql-statements/sql-statement-insert.md
@@ -15,6 +15,10 @@ This statement inserts new rows into a table.
 
 ![InsertIntoStmt](/media/sqlgram/InsertIntoStmt.png)
 
+**TableOptimizerHints**
+
+![TableOptimizerHints](/media/sqlgram/TableOptimizerHints.png)
+
 **PriorityOpt:**
 
 ![PriorityOpt](/media/sqlgram/PriorityOpt.png)
@@ -31,14 +35,22 @@ This statement inserts new rows into a table.
 
 ![TableName](/media/sqlgram/TableName.png)
 
+**PartitionNameListOpt:**
+
+![PartitionNameListOpt](/media/sqlgram/PartitionNameListOpt.png)
+
 **InsertValues:**
 
 ![InsertValues](/media/sqlgram/InsertValues.png)
 
+**OnDuplicateKeyUpdate:**
+
+![OnDuplicateKeyUpdate](/media/sqlgram/OnDuplicateKeyUpdate.png)
+
 ## Examples
 
 ```sql
-mysql> CREATE TABLE t1 (a int);
+mysql> CREATE TABLE t1 (a INT);
 Query OK, 0 rows affected (0.11 sec)
 
 mysql> CREATE TABLE t2 LIKE t1;

diff --git a/sql-statements/sql-statement-replace.md b/sql-statements/sql-statement-replace.md
@@ -27,6 +27,10 @@ The `REPLACE` statement is semantically a combined `DELETE`+`INSERT` statement.
 
 ![TableName](/media/sqlgram/TableName.png)
 
+**PartitionNameListOpt:**
+
+![PartitionNameListOpt](/media/sqlgram/PartitionNameListOpt.png)
+
 **InsertValues:**
 
 ![InsertValues](/media/sqlgram/InsertValues.png)

diff --git a/sql-statements/sql-statement-rollback.md b/sql-statements/sql-statement-rollback.md
@@ -11,14 +11,14 @@ This statement reverts all changes in the current transaction inside of TIDB.  I
 
 ## Synopsis
 
-**Statement:**
+**RollbackStmt:**
 
-![Statement](/media/sqlgram/Statement.png)
+![RollbackStmt](/media/sqlgram/RollbackStmt.png)
 
 ## Examples
 
 ```sql
-mysql> CREATE TABLE t1 (a int NOT NULL PRIMARY KEY);
+mysql> CREATE TABLE t1 (a INT NOT NULL PRIMARY KEY);
 Query OK, 0 rows affected (0.12 sec)
 
 mysql> BEGIN;
@@ -36,7 +36,7 @@ Empty set (0.01 sec)
 
 ## MySQL compatibility
 
-This statement is understood to be fully compatible with MySQL. Any compatibility differences should be [reported via an issue](/report-issue.md) on GitHub.
+This statement is partly compatible with MySQL. TiDB only has syntactic support for `CompletionTypeWithinTransaction`. Closing the connection or continuing to open a new transaction after the transaction is rolled back is not supported. Any compatibility differences should be [reported via an issue](/report-issue.md) on GitHub.
 
 ## See also
 

diff --git a/sql-statements/sql-statement-set-transaction.md b/sql-statements/sql-statement-set-transaction.md
@@ -26,7 +26,7 @@ The `SET TRANSACTION` statement can be used to change the current isolation leve
 ## Examples
 
 ```sql
-mysql> SHOW SESSION VARIABLES like 'transaction_isolation';
+mysql> SHOW SESSION VARIABLES LIKE 'transaction_isolation';
 +-----------------------+-----------------+
 | Variable_name         | Value           |
 +-----------------------+-----------------+
@@ -37,7 +37,7 @@ mysql> SHOW SESSION VARIABLES like 'transaction_isolation';
 mysql> SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
 Query OK, 0 rows affected (0.00 sec)
 
-mysql> SHOW SESSION VARIABLES like 'transaction_isolation';
+mysql> SHOW SESSION VARIABLES LIKE 'transaction_isolation';
 +-----------------------+----------------+
 | Variable_name         | Value          |
 +-----------------------+----------------+
@@ -48,7 +48,7 @@ mysql> SHOW SESSION VARIABLES like 'transaction_isolation';
 mysql> SET SESSION transaction_isolation = 'REPEATABLE-READ';
 Query OK, 0 rows affected (0.00 sec)
 
-mysql> SHOW SESSION VARIABLES like 'transaction_isolation';
+mysql> SHOW SESSION VARIABLES LIKE 'transaction_isolation';
 +-----------------------+-----------------+
 | Variable_name         | Value           |
 +-----------------------+-----------------+
@@ -61,7 +61,8 @@ mysql> SHOW SESSION VARIABLES like 'transaction_isolation';
 
 * TiDB supports the ability to set a transaction as read-only in syntax only.
 * The isolation levels `READ-UNCOMMITTED` and `SERIALIZABLE` are not supported.
-* The isolation level `REPEATABLE-READ` is technically Snapshot Isolation. The name `REPEATABLE-READ` is used for compatibility with MySQL.
+* The `REPEATABLE-READ` isolation level is achieved through using the snapshot isolation technology, which is partly compatible with MySQL.
+* In pessimistic transactions, TiDB supports two isolation levels compatible with MySQL: `REPEATABLE-READ` and `READ-COMMITTED`. For a detailed description, see [Isolation Levels](/transaction-isolation-levels.md).
 
 ## See also
 

diff --git a/sql-statements/sql-statement-start-transaction.md b/sql-statements/sql-statement-start-transaction.md
@@ -7,7 +7,7 @@ aliases: ['/docs/stable/reference/sql/statements/start-transaction/']
 
 # START TRANSACTION
 
-This statement starts a new transaction inside of TiDB. It is similar to the statements `BEGIN` and `SET autocommit=0`.
+This statement starts a new transaction inside of TiDB. It is similar to the statement `BEGIN`.
 
 In the absence of a `START TRANSACTION` statement, every statement will by default autocommit in its own transaction. This behavior ensures MySQL compatibility.
 
@@ -35,7 +35,12 @@ Query OK, 0 rows affected (0.01 sec)
 
 ## MySQL compatibility
 
-This statement is understood to be fully compatible with MySQL. Any compatibility differences should be [reported via an issue](/report-issue.md) on GitHub.
+This statement is understood to be partly compatible with MySQL.
+
+* `START TRANSACTION` is equivalent to MySQL’s `START TRANSACTION WITH CONSISTENT SNAPSHOT`, that is, after `START TRANSACTION`, a `SELECT` statement (not `SELECT FOR UPDATE`) is executed to read data from any table in InnoDB.
+* `READ ONLY` and its extended options are only syntactically compatible, and its effect is equivalent to `START TRANSACTION`.
+
+Any compatibility differences should be [reported via an issue](/report-issue.md) on GitHub.
 
 ## See also