Update docs of SHARD_ROW_ID_BITS (pingcap#12891)

clustered-indexes.md

@@ -61,7 +61,7 @@ CREATE TABLE t (a BIGINT, b VARCHAR(255), PRIMARY KEY(a, b) /*T![clustered_index
 CREATE TABLE t (a BIGINT, b VARCHAR(255), PRIMARY KEY(a, b) /*T![clustered_index] NONCLUSTERED */);
 ```
 
-For statements that do not explicitly specify the keyword `CLUSTERED`/`NONCLUSTERED`, the default behavior is controlled by the system variable `@@global.tidb_enable_clustered_index`. Supported values for this variable are as follows:
+For statements that do not explicitly specify the keyword `CLUSTERED`/`NONCLUSTERED`, the default behavior is controlled by the system variable [`@@global.tidb_enable_clustered_index`](/system-variables.md#tidb_enable_clustered_index-new-in-v50). Supported values for this variable are as follows:
 
 - `OFF` indicates that primary keys are created as non-clustered indexes by default.
 - `ON` indicates that primary keys are created as clustered indexes by default.

shard-row-id-bits.md

@@ -9,15 +9,34 @@ This document introduces the `SHARD_ROW_ID_BITS` table attribute, which is used
 
 ## Concept
 
-For the tables with a non-integer primary key or no primary key, TiDB uses an implicit auto-increment row ID. When a large number of `INSERT` operations are performed, the data is written into a single Region, causing a write hot spot.
+For the tables with a non-clustered primary key or no primary key, TiDB uses an implicit auto-increment row ID. When a large number of `INSERT` operations are performed, the data is written into a single Region, causing a write hot spot.
 
 To mitigate the hot spot issue, you can configure `SHARD_ROW_ID_BITS`. The row IDs are scattered and the data are written into multiple different Regions.
 
 - `SHARD_ROW_ID_BITS = 4` indicates 16 shards
 - `SHARD_ROW_ID_BITS = 6` indicates 64 shards
 - `SHARD_ROW_ID_BITS = 0` indicates the default 1 shard
 
+<CustomContent platform="tidb">
+
+For details on the usage, see [the Troubleshoot Hotspot Issues guide](/troubleshoot-hot-spot-issues.md#use-shard_row_id_bits-to-process-hotspots).
+
+</CustomContent>
+
+<CustomContent platform="tidb-cloud">
+
+For details on the usage, see [the Troubleshoot Hotspot Issues guide](https://docs.pingcap.com/tidb/stable/troubleshoot-hot-spot-issues#use-shard_row_id_bits-to-process-hotspots).
+
+</CustomContent>
+
 ## Examples
 
-- `CREATE TABLE`: `CREATE TABLE t (c int) SHARD_ROW_ID_BITS = 4;`
-- `ALTER TABLE`: `ALTER TABLE t SHARD_ROW_ID_BITS = 4;`
+```sql
+CREATE TABLE t (
+    id INT PRIMARY KEY NONCLUSTERED
+) SHARD_ROW_ID_BITS = 4;
+```
+
+```sql
+ALTER TABLE t SHARD_ROW_ID_BITS = 4;
+```

troubleshoot-hot-spot-issues.md

@@ -87,9 +87,9 @@ Hover over the bright block, you can see what table or index has a heavy load. F
 
 ## Use `SHARD_ROW_ID_BITS` to process hotspots
 
-For a non-integer primary key or a table without a primary key or a joint primary key, TiDB uses an implicit auto-increment RowID. When a large number of `INSERT` operations exist, the data is written into a single Region, resulting in a write hotspot.
+For a non-clustered primary key or a table without a primary key, TiDB uses an implicit auto-increment RowID. When a large number of `INSERT` operations exist, the data is written into a single Region, resulting in a write hotspot.
 
-By setting `SHARD_ROW_ID_BITS`, row IDs are scattered and written into multiple Regions, which can alleviate the write hotspot issue.
+By setting [`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md), row IDs are scattered and written into multiple Regions, which can alleviate the write hotspot issue.
 
 ```
 SHARD_ROW_ID_BITS = 4 # Represents 16 shards.