Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update auto increment by adding explanations #20390

Merged
merged 2 commits into from
Mar 3, 2025
Merged

Update auto increment by adding explanations #20390

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
75b0d2d
Update auto increment by adding explanations
lilin90 Feb 27, 2025
b945708
Update wording
lilin90 Feb 27, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 4 additions & 1 deletion auto-increment.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -457,11 +457,14 @@ INSERT INTO t VALUES (); -- Returns ID 30001
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.

- During failover when the primary instance exits or crashes

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 if you access across TiDB instances, the IDs will keep monotonic. Only when the primary instance of the centralized service crashes, there might be a few IDs that are not continuous. This is because the secondary instance discards some IDs that are supposed to have been allocated by the primary instance during the failover to ensure ID uniqueness.

- During rolling upgrades of TiDB nodes
- During normal concurrent transactions (similar to MySQL)

> **Note:**
>
>
> The behavior and performance of `AUTO_ID_CACHE 1` has evolved across TiDB versions:
>
> - Before v6.4.0, each ID allocation requires a TiKV transaction, which affects performance.
Expand Down