kmfkaccounting.blogg.se

Instance A might cache the auto-increment IDs of, and instance B might cache the auto-increment IDs of.

If you execute an INSERT statement on the t table on A and B respectively: INSERT INTO t (c) VALUES (1) For example: CREATE TABLE t(id int UNIQUE KEY AUTO_INCREMENT, c int) Īssume two TiDB instances, A and B, in the cluster. Therefore, TiDB nodes do not apply to the storage node for IDs when assigning IDs each time. Therefore, to avoid the issue of write amplification, each TiDB node applies for a batch of consecutive IDs as caches when assigning IDs, and then applies for the next batch of IDs after the first batch is assigned. In a distributed environment, communication between nodes has some overhead. TiDB implements the AUTO_INCREMENT implicit assignment in the following way:įor each auto-increment column, a globally visible key-value pair is used to record the maximum ID that has been assigned. However, in terms of the specific value that is implicitly assigned, TiDB differs from MySQL significantly. The usage above is the same as that of AUTO_INCREMENT in MySQL. In such cases, TiDB stores the explicitly specified values: INSERT INTO t(id, c) VALUES (6, 6)

In addition, AUTO_INCREMENT also supports the INSERT statements that explicitly specify column values. The following is a basic example of AUTO_INCREMENT: CREATE TABLE t(id int PRIMARY KEY AUTO_INCREMENT, c int) If you want the AUTO_INCREMENT numbers to be monotonic on all TiDB servers and your TiDB version is v6.5.0 or later, it is recommended to enable the MySQL compatibility mode.