From 8d631bb6eb65c31fab2b19410635102c097bedae Mon Sep 17 00:00:00 2001 From: Shuaipeng Yu Date: Mon, 15 Jun 2020 11:51:48 +0800 Subject: [PATCH 1/3] update several statements Signed-off-by: Shuaipeng Yu --- sql-statements/sql-statement-commit.md | 1 + sql-statements/sql-statement-execute.md | 4 ---- sql-statements/sql-statement-insert.md | 14 +++++++++++++- sql-statements/sql-statement-replace.md | 4 ++++ sql-statements/sql-statement-rollback.md | 8 ++++---- sql-statements/sql-statement-set-transaction.md | 9 +++++---- sql-statements/sql-statement-start-transaction.md | 9 +++++++-- 7 files changed, 34 insertions(+), 15 deletions(-) diff --git a/sql-statements/sql-statement-commit.md b/sql-statements/sql-statement-commit.md index 34ac13e923a65..d28b3ac7ad587 100644 --- a/sql-statements/sql-statement-commit.md +++ b/sql-statements/sql-statement-commit.md @@ -37,6 +37,7 @@ Query OK, 0 rows affected (0.01 sec) * 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`. +* TiDB only has syntactic support for `CompletionTypeWithinTransaction`. Closing the connection or continuing to open a new transaction commit option is not supported. ## See also diff --git a/sql-statements/sql-statement-execute.md b/sql-statements/sql-statement-execute.md index 3b520e73ae42a..13e0e47a2736d 100644 --- 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 index f1f6196d03f75..9858a3a8f1361 100644 --- 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 index 3f460f3a09f0d..5535de717f4a9 100644 --- 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 index f5ba4cae311ef..74406a6d9dd8e 100644 --- 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 commit option 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 index 71184d5522336..0de2bd9b1eea4 100644 --- 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. +* Snapshot isolation (Snapshot Isolation) technology to achieve optimistic transaction `REPEATABLE-READ` isolation level, 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 index 263ee88124d56..6c615494d4b77 100644 --- a/sql-statements/sql-statement-start-transaction.md +++ b/sql-statements/sql-statement-start-transaction.md @@ -7,7 +7,7 @@ aliases: ['/docs/dev/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 statements `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 From 5350f6c14836b1684c7ba8daecfad32eb04d493e Mon Sep 17 00:00:00 2001 From: Jack Yu Date: Mon, 15 Jun 2020 16:08:25 +0800 Subject: [PATCH 2/3] Apply suggestions from code review Co-authored-by: Ran --- sql-statements/sql-statement-commit.md | 4 ++-- sql-statements/sql-statement-rollback.md | 2 +- sql-statements/sql-statement-set-transaction.md | 2 +- sql-statements/sql-statement-start-transaction.md | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/sql-statements/sql-statement-commit.md b/sql-statements/sql-statement-commit.md index d28b3ac7ad587..c3e7612ce0a2a 100644 --- a/sql-statements/sql-statement-commit.md +++ b/sql-statements/sql-statement-commit.md @@ -36,8 +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`. -* TiDB only has syntactic support for `CompletionTypeWithinTransaction`. Closing the connection or continuing to open a new transaction commit option is not supported. +* Be default, `UNIQUE` and `PRIMARY KEY` constraint checks are defered 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-rollback.md b/sql-statements/sql-statement-rollback.md index 74406a6d9dd8e..d8d07c65bdd3e 100644 --- a/sql-statements/sql-statement-rollback.md +++ b/sql-statements/sql-statement-rollback.md @@ -36,7 +36,7 @@ Empty set (0.01 sec) ## MySQL compatibility -This statement is partly compatible with MySQL. TiDB only has syntactic support for `CompletionTypeWithinTransaction`. Closing the connection or continuing to open a new transaction commit option is not supported. 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 index 0de2bd9b1eea4..e02fc5ea1e51c 100644 --- a/sql-statements/sql-statement-set-transaction.md +++ b/sql-statements/sql-statement-set-transaction.md @@ -61,7 +61,7 @@ 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. -* Snapshot isolation (Snapshot Isolation) technology to achieve optimistic transaction `REPEATABLE-READ` isolation level, partly compatible 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 index 6c615494d4b77..ab71c2c8fb41d 100644 --- a/sql-statements/sql-statement-start-transaction.md +++ b/sql-statements/sql-statement-start-transaction.md @@ -7,7 +7,7 @@ aliases: ['/docs/dev/reference/sql/statements/start-transaction/'] # START TRANSACTION -This statement starts a new transaction inside of TiDB. It is similar to the statements `BEGIN`. +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. From a5ac74c340e8807e2a7d5f03e2a104d1a00a5610 Mon Sep 17 00:00:00 2001 From: Ran Date: Mon, 15 Jun 2020 16:15:05 +0800 Subject: [PATCH 3/3] Update sql-statements/sql-statement-commit.md --- sql-statements/sql-statement-commit.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sql-statements/sql-statement-commit.md b/sql-statements/sql-statement-commit.md index c3e7612ce0a2a..5f2b5d31a29eb 100644 --- a/sql-statements/sql-statement-commit.md +++ b/sql-statements/sql-statement-commit.md @@ -36,7 +36,7 @@ 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 defered 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