diff --git a/auto-increment.md b/auto-increment.md
index 29d923093db09..99f878d8a2b0c 100644
--- a/auto-increment.md
+++ b/auto-increment.md
@@ -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 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.
+
 - 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.