diff --git a/TOC.md b/TOC.md
index ad1f7d71200b6..685b060bcbe0c 100644
--- a/TOC.md
+++ b/TOC.md
@@ -203,6 +203,7 @@
       + Attributes
         + [AUTO_INCREMENT](/auto-increment.md)
         + [AUTO_RANDOM](/auto-random.md)
+        + [SHARD_ROW_ID_BITS](/shard-row-id-bits.md)
       + [Literal Values](/literal-values.md)
       + [Schema Object Names](/schema-object-names.md)
       + [Keywords and Reserved Words](/keywords.md)
diff --git a/best-practices/high-concurrency-best-practices.md b/best-practices/high-concurrency-best-practices.md
index be0dca2d4aaab..5687acdbb3fb7 100644
--- a/best-practices/high-concurrency-best-practices.md
+++ b/best-practices/high-concurrency-best-practices.md
@@ -181,7 +181,7 @@ In this case, the table is simple. In other cases, you might also need to consid
 
 **Problem one:**
 
-If a table does not have a primary key, or the primary key is not the `Int` type and you do not want to generate a randomly distributed primary key ID, TiDB provides an implicit `_tidb_rowid` column as the row ID. Generally, when you do not use the `SHARD_ROW_ID_BITS` parameter, the values of the `_tidb_rowid` column are also monotonically increasing, which might causes hotspots too. Refer to [`SHARD_ROW_ID_BITS` description](/tidb-specific-system-variables.md#shard_row_id_bits) for more details.
+If a table does not have a primary key, or the primary key is not the `Int` type and you do not want to generate a randomly distributed primary key ID, TiDB provides an implicit `_tidb_rowid` column as the row ID. Generally, when you do not use the `SHARD_ROW_ID_BITS` parameter, the values of the `_tidb_rowid` column are also monotonically increasing, which might causes hotspots too. Refer to [`SHARD_ROW_ID_BITS` description](/shard-row-id-bits.md) for more details.
 
 To avoid the hotspot problem in this situation, you can use `SHARD_ROW_ID_BITS` and `PRE_SPLIT_REGIONS` when creating a table. For more details about `PRE_SPLIT_REGIONS`, refer to [Pre-split Regions](/sql-statements/sql-statement-split-region.md#pre_split_regions).
 
diff --git a/faq/tidb-faq.md b/faq/tidb-faq.md
index 03cc0a6bf2dee..3d69c4f8d4e9c 100644
--- a/faq/tidb-faq.md
+++ b/faq/tidb-faq.md
@@ -1089,7 +1089,7 @@ See [The TiDB Command Options](/command-line-flags-for-tidb-configuration.md).
 
 #### How to scatter the hotspots?
 
-In TiDB, data is divided into Regions for management. Generally, the TiDB hotspot means the Read/Write hotspot in a Region. In TiDB, for the table whose primary key (PK) is not an integer or which has no PK, you can properly break Regions by configuring `SHARD_ROW_ID_BITS` to scatter the Region hotspots. For details, see the introduction of `SHARD_ROW_ID_BITS` in [TiDB Specific System Variables and Syntax](/tidb-specific-system-variables.md#shard_row_id_bits).
+In TiDB, data is divided into Regions for management. Generally, the TiDB hotspot means the Read/Write hotspot in a Region. In TiDB, for the table whose primary key (PK) is not an integer or which has no PK, you can properly break Regions by configuring `SHARD_ROW_ID_BITS` to scatter the Region hotspots. For details, see the introduction of `SHARD_ROW_ID_BITS` in [TiDB Specific System Variables and Syntax](/shard-row-id-bits.md).
 
 ### TiKV
 
diff --git a/shard-row-id-bits.md b/shard-row-id-bits.md
new file mode 100644
index 0000000000000..e5ec90ea1de65
--- /dev/null
+++ b/shard-row-id-bits.md
@@ -0,0 +1,23 @@
+---
+title: SHARD_ROW_ID_BITS
+summary: Learn the SHARD_ROW_ID_BITS attribute.
+---
+
+# SHARD_ROW_ID_BITS
+
+This document introduces the `SHARD_ROW_ID_BITS` table attribute, which is used to set the number of bits of the implicit sharded `_tidb_rowid`.
+
+## 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.
+
+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. But setting an overlarge value might lead to an excessively large number of RPC requests, which increases the CPU and network overheads.
+
+- `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
+
+## Examples
+
+- `CREATE TABLE`: `CREATE TABLE t (c int) SHARD_ROW_ID_BITS = 4;`
+- `ALTER TABLE`: `ALTER TABLE t SHARD_ROW_ID_BITS = 4;`
diff --git a/sql-statements/sql-statement-create-table.md b/sql-statements/sql-statement-create-table.md
index 0f4996704a67c..ba4571db1d5fc 100644
--- a/sql-statements/sql-statement-create-table.md
+++ b/sql-statements/sql-statement-create-table.md
@@ -225,7 +225,7 @@ table_option:
   | STATS_PERSISTENT [=] {DEFAULT|0|1}
 ```
 
-The `table_option` currently only supports `AUTO_INCREMENT`, `SHARD_ROW_ID_BITS` (see [TiDB Specific System Variables](/tidb-specific-system-variables.md#shard_row_id_bits) for details), `PRE_SPLIT_REGIONS`, `CHARACTER SET`, `COLLATE`, and `COMMENT`, while the others are only supported in syntax. The clauses are separated by a comma `,`. See the following table for details:
+The `table_option` currently only supports `AUTO_INCREMENT`, `SHARD_ROW_ID_BITS` (see [TiDB Specific System Variables](/shard-row-id-bits.md) for details), `PRE_SPLIT_REGIONS`, `CHARACTER SET`, `COLLATE`, and `COMMENT`, while the others are only supported in syntax. The clauses are separated by a comma `,`. See the following table for details:
 
 | Parameters | Description | Example |
 | ---------- | ---------- | ------- |