diff --git a/system-variables.md b/system-variables.md
index 7e33c462500e2..317764bf16bd3 100644
--- a/system-variables.md
+++ b/system-variables.md
@@ -3212,7 +3212,7 @@ For a system upgraded to v5.0 from an earlier version, if you have not modified
 - Default value: `32`
 - Range: `[1, 32]`
 - Unit: Rows
-- This variable is used to set the number of rows for the initial chunk during the execution process.
+- This variable is used to set the number of rows for the initial chunk during the execution process. The number of rows for a chunk directly affects the amount of memory required for a single query. You can roughly estimate the memory needed for a single chunk by considering the total width of all columns in the query and the number of rows for the chunk. Combining this with the concurrency of the executor, you can make a rough estimation of the total memory required for a single query. It is recommended that the total memory for a single chunk does not exceed 16 MiB.
 
 ### tidb_isolation_read_engines <span class="version-mark">New in v4.0</span>
 
@@ -3441,7 +3441,7 @@ For a system upgraded to v5.0 from an earlier version, if you have not modified
 - Default value: `1024`
 - Range: `[32, 2147483647]`
 - Unit: Rows
-- This variable is used to set the maximum number of rows in a chunk during the execution process. Setting to too large of a value may cause cache locality issues.
+- This variable is used to set the maximum number of rows in a chunk during the execution process. Setting to too large of a value may cause cache locality issues. The recommended value for this variable is no larger than 65536. The number of rows for a chunk directly affects the amount of memory required for a single query. You can roughly estimate the memory needed for a single chunk by considering the total width of all columns in the query and the number of rows for the chunk. Combining this with the concurrency of the executor, you can make a rough estimation of the total memory required for a single query. It is recommended that the total memory for a single chunk does not exceed 16 MiB. When the query involves a large amount of data and a single chunk is insufficient to handle all the data, TiDB processes it multiple times, doubling the chunk size with each processing iteration, starting from [`tidb_init_chunk_size`](#tidb_init_chunk_size) until the chunk size reaches the value of `tidb_max_chunk_size`.
 
 ### tidb_max_delta_schema_count <span class="version-mark">New in v2.1.18 and v3.0.5</span>
 
diff --git a/transaction-isolation-levels.md b/transaction-isolation-levels.md
index 1a78c24e6e4f4..013458019638a 100644
--- a/transaction-isolation-levels.md
+++ b/transaction-isolation-levels.md
@@ -77,7 +77,7 @@ Starting from v6.0.0, TiDB supports using the [`tidb_rc_read_check_ts`](/system-
 - If TiDB does not encounter any data update during the read process, it returns the result to the client and the `SELECT` statement is successfully executed.
 - If TiDB encounters data update during the read process:
     - If TiDB has not yet sent the result to the client, TiDB tries to acquire a new timestamp and retry this statement.
-    - If TiDB has already sent partial data to the client, TiDB reports an error to the client. The amount of data sent to the client each time is controlled by `tidb_init_chunk_size` and `tidb_max_chunk_size`.
+    - If TiDB has already sent partial data to the client, TiDB reports an error to the client. The amount of data sent to the client each time is controlled by [`tidb_init_chunk_size`](/system-variables.md#tidb_init_chunk_size) and [`tidb_max_chunk_size`](/system-variables.md#tidb_max_chunk_size).
 
 In scenarios where the `READ-COMMITTED` isolation level is used, the `SELECT` statements are many, and read-write conflicts are rare, enabling this variable can avoid the latency and cost of getting the global timestamp.