diff --git a/auto-increment.md b/auto-increment.md
index 3ad0cb1a4d196..00bfa14c09c4e 100644
--- a/auto-increment.md
+++ b/auto-increment.md
@@ -455,7 +455,7 @@ While IDs are always increasing and without significant gaps like those seen wit
 
 - 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.
+    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)