You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
sql: update the description of auto id conflicts (#488)
* sql: update the description of auto id conflicts
Via: pingcap/docs-cn#758
* sql: add whitespace to closed intervals
* sql: update wording to address comments
Copy file name to clipboardExpand all lines: sql/mysql-compatibility.md
+9-5Lines changed: 9 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -32,18 +32,22 @@ The auto-increment ID feature in TiDB is only guaranteed to be automatically inc
32
32
33
33
> **Warning**:
34
34
>
35
-
> If you use the auto-increment ID in a cluster with multiple TiDB servers, do not mix the default value and the custom value, because it reports an error in the following situation:
35
+
> If you use the auto-increment ID in a cluster with multiple tidb-server instances, do not mix the default value and the custom value, otherwise an error occurs in the following situation:
36
36
>
37
-
> In a cluster of two TiDB servers, namely TiDB A and TiDB B, TiDB A caches [1,5000] auto-increment ID, while TiDB B caches [5001,10000] auto-increment ID. Use the following statement to create a table with auto-increment ID:
37
+
> Assume that you have a table with the auto-increment ID:
38
38
>
39
39
> ```
40
40
> create table t(id int unique key auto_increment, c int);
41
41
> ```
42
+
>
43
+
> The principle of the auto-increment ID in TiDB is that each tidb-server instance caches a section of ID values for allocation and fetches the next section after this section is used up.
42
44
>
43
-
> The statement is executed as follows:
45
+
> Assume that the cluster contains two tidb-server instances, namely Instance A and Instance B. Instance A caches the auto-increment ID of [1, 5000], while Instance B caches the auto-increment ID of [5001, 10000].
46
+
>
47
+
> The operations are executed as follows:
44
48
>
45
-
> 1. The client inserts a statement to TiDB B which sets the `id` to be 1 and the statement is executed successfully.
46
-
> 2. The client inserts a record to TiDB A which sets the `id` set to the default value 1. In this case, it returns `Duplicated Error`.
49
+
> 1. The client issues the `insert into t values (1, 1)` statement to Instance B which sets the `id` to 1 and the statement is executed successfully.
50
+
> 2. The client issues the `insert into t (c) (1)` statement to Instance A. This statement does not specify the value of `id`, so Instance A allocates the value. Currently, Instances A caches the auto-increment ID of [1, 5000], so it allocates the `id` value to 1 and adds 1 to the local counter. However, at this time the data with the `id` of 1 already exists in the cluster, therefore it reports `Duplicated Error`.
0 commit comments