docs: clarify AUTO_RANDOM_BASE usage and explicit insert behavior

auto-random.md

@@ -166,30 +166,39 @@ TiDB implicitly allocates values to `AUTO_RANDOM` columns similarly to `AUTO_INC
 
 ## Clear the auto-increment ID cache
 
-Explicitly inserting data into an `AUTO_RANDOM` column behaves the same as with an `AUTO_INCREMENT` column, so you also need to clear the auto-increment ID cache. For more details, see [Clear the auto-increment ID cache](/auto-increment.md#clear-the-auto-increment-id-cache).
+When you insert explicit values into an `AUTO_RANDOM` column in a multi-instance TiDB deployment, ID collisions might occur, similar to an `AUTO_INCREMENT` column. Errors occur when the explicitly inserted ID conflicts with the internal counter that TiDB uses for automatic ID generation. 
 
-You can run the `ALTER TABLE` statement to set `AUTO_RANDOM_BASE=0` to clear the auto-increment ID cache on all TiDB nodes in the cluster. For example:
+The collision happens as follows: each `AUTO_RANDOM` ID contains an auto-incrementing part alongside random bits. TiDB uses an internal counter for this auto-incrementing part. If you explicitly insert an ID where the auto-incrementing part matches the counter's next value, a duplicate key error might occur when TiDB later attempts to generate the same ID automatically. For more details, see [AUTO_INCREMENT Uniqueness](/auto-increment.md#uniqueness).
+
+In a single TiDB instance, this issue does not occur because the node automatically adjusts its internal counter when processing explicit insertions, preventing any future collisions. However, in a multi-instance TiDB deployment, each node maintains its own cache of IDs, which needs to be cleared after explicit insertions to prevent collisions. You can clear the unallocated cached IDs and avoid collisions using one of the following options.
+
+### Option 1: Automatically rebase (Recommended)
 
 ```sql
 ALTER TABLE t AUTO_RANDOM_BASE=0;
 ```
 
-```
-Query OK, 0 rows affected, 1 warning (0.52 sec)
-```
+This statement automatically determines an appropriate base value. Although it produces a warning message similar to `Can't reset AUTO_INCREMENT to 0 without FORCE option, using XXX instead`, the value **will** change and you can safely ignore this warning.
+
+> **Note:**
+>
+> You cannot set `AUTO_RANDOM_BASE` to `0` with the `FORCE` keyword. Attempting this results in an error.
+
+### Option 2: Manually set a specific base value
+
+If you need to set a specific base value (for example, `1000`), use the `FORCE` keyword:
 
 ```sql
-SHOW WARNINGS;
+ALTER TABLE t FORCE AUTO_RANDOM_BASE = 1000;
 ```
 
-```
-+---------+------+-------------------------------------------------------------------------+
-| Level   | Code | Message                                                                 |
-+---------+------+-------------------------------------------------------------------------+
-| Warning | 1105 | Can't reset AUTO_INCREMENT to 0 without FORCE option, using 101 instead |
-+---------+------+-------------------------------------------------------------------------+
-1 row in set (0.00 sec)
-```
+This approach is less convenient because it requires you to determine an appropriate value yourself.
+
+> **Note:**
+>
+> You must use a non-zero positive integer value when using `FORCE`.
+
+Both statements in these two options modify the starting point for the auto-increment bits used in subsequent `AUTO_RANDOM` value generations across all TiDB nodes. They do not affect already allocated IDs.
 
 ## Restrictions