Skip to content

Commit 7c7077b

Browse files
authored
Update auto increment by adding explanations (pingcap#20390) (pingcap#20439)
1 parent 930b284 commit 7c7077b

1 file changed

Lines changed: 4 additions & 1 deletion

File tree

auto-increment.md

Lines changed: 4 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -454,11 +454,14 @@ INSERT INTO t VALUES (); -- Returns ID 30001
454454
While IDs are always increasing and without significant gaps like those seen with `AUTO_ID_CACHE 0`, small gaps in the sequence might still occur in the following scenarios. These gaps are necessary to maintain both uniqueness and the strictly increasing property of the IDs.
455455
456456
- During failover when the primary instance exits or crashes
457+
458+
After you enable the MySQL compatibility mode, the allocated IDs are **unique** and **monotonically increasing**, and the behavior is almost the same as MySQL. Even when accessing across multiple TiDB instances, ID monotonicity is maintained. However, if the primary instance of the centralized service crashes, a few IDs might become non-continuous. This occurs because the secondary instance discards some IDs allocated by the primary instance during failover to ensure ID uniqueness.
459+
457460
- During rolling upgrades of TiDB nodes
458461
- During normal concurrent transactions (similar to MySQL)
459462
460463
> **Note:**
461-
>
464+
>
462465
> The behavior and performance of `AUTO_ID_CACHE 1` has evolved across TiDB versions:
463466
>
464467
> - Before v6.4.0, each ID allocation requires a TiKV transaction, which affects performance.

0 commit comments

Comments
 (0)