diff --git a/develop/dev-guide-timeouts-in-tidb.md b/develop/dev-guide-timeouts-in-tidb.md
index 9c47b37ec5f3f..9917ec0ca95a0 100644
--- a/develop/dev-guide-timeouts-in-tidb.md
+++ b/develop/dev-guide-timeouts-in-tidb.md
@@ -54,6 +54,8 @@ SQL statements such as `INSERT INTO t10 SELECT * FROM t1` are not affected by GC
 
 TiDB also provides a system variable (`max_execution_time`, `0` by default, indicating no limit) to limit the execution time of a single SQL statement. Currently, the system variable only takes effect for `SELECT` statements (including `SELECT ... FOR UPDATE`). The unit of `max_execution_time` is `ms`, but the actual precision is at the `100ms` level instead of the millisecond level.
 
+Starting from v8.5.9 and v9.0.0, to limit the execution time of transactional `INSERT`, `REPLACE`, `UPDATE`, and `DELETE` statements, and `COMMIT` statements, use [`tidb_dml_max_execution_time`](/system-variables.md#tidb_dml_max_execution_time-new-in-v859-and-v900). Its default value is `0` (no limit), and its unit is milliseconds. For autocommit DML, the limit includes the commit phase. The limit does not apply to non-transactional DML, Pipelined DML, or certain batch operations. For the complete scope and limitations, see the variable description.
+
 ## JDBC query timeout
 
 Starting from v6.1.0, when the [`enable-global-kill`](/tidb-configuration-file.md#enable-global-kill-new-in-v610) configuration item is set to its default value `true`, you can use the `setQueryTimeout()` method provided by MySQL JDBC to control the query timeout.
diff --git a/system-variable-reference.md b/system-variable-reference.md
index 3590ce3e5c8fd..f48776f425398 100644
--- a/system-variable-reference.md
+++ b/system-variable-reference.md
@@ -1344,6 +1344,13 @@ Referenced in:
 - [TiDB 5.0 Release Notes](/releases/release-5.0.0.md)
 - [TiDB 4.0 Beta Release Notes](/releases/release-4.0.0-beta.md)
 
+### tidb_dml_max_execution_time
+
+Referenced in:
+
+- [System Variables](/system-variables.md#tidb_dml_max_execution_time-new-in-v859-and-v900)
+- [Timeouts in TiDB](/develop/dev-guide-timeouts-in-tidb.md)
+
 ### tidb_dml_type
 
 Referenced in:
diff --git a/system-variables.md b/system-variables.md
index ce7bf4e26cb5e..bc520d8e9e666 100644
--- a/system-variables.md
+++ b/system-variables.md
@@ -1945,6 +1945,29 @@ Assume that you have a cluster with 4 TiDB nodes and multiple TiKV nodes. In thi
 >
 > Starting from v7.0.0, `tidb_dml_batch_size` no longer takes effect on the [`LOAD DATA` statement](/sql-statements/sql-statement-load-data.md).
 
+### tidb_dml_max_execution_time <span class="version-mark">New in v8.5.9 and v9.0.0</span>
+
+- Scope: SESSION | GLOBAL
+- Persists to cluster: Yes
+- Applies to hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value): Yes
+- Type: Integer
+- Default value: `0`
+- Range: `[0, 2147483647]`
+- Unit: Milliseconds
+- This variable limits the maximum execution time of transactional `INSERT`, `REPLACE`, `UPDATE`, and `DELETE` statements, and `COMMIT` statements. The default value `0` means no limit from this variable.
+- For an autocommit DML statement, the limit includes the time spent committing the transaction. In an explicit transaction, the limit applies separately to each DML statement and to `COMMIT`, rather than to the total duration of the transaction.
+- This variable does not apply to the following operations:
+    - [Non-transactional DML statements](/non-transactional-dml.md).
+    - DML statements executed using the deprecated batch-dml feature, or DML and `COMMIT` statements when [`tidb_batch_commit`](#tidb_batch_commit) is enabled.
+    - Statements executed using [Pipelined DML](/pipelined-dml.md). If `tidb_dml_type = 'bulk'` is set but the statement falls back to ordinary DML execution, this variable still applies.
+    - `EXPLAIN ANALYZE` statements and statement types other than those listed above, such as `LOAD DATA` and `IMPORT INTO`.
+
+> **Note:**
+>
+> - The statement might finish later than the configured timeout.
+> - For `COMMIT` and autocommit DML statements, if the statement times out and TiDB cannot determine whether the transaction has committed, it closes the client connection. The client might receive a connection error instead of a statement timeout error. A connection loss does not mean that the transaction has been rolled back; the transaction might have committed.
+> - When enabling this variable, it is recommended to set a relatively long timeout and allow sufficient headroom for normal DML execution and transaction commits. After TiDB interrupts a statement, requests already sent to TiKV might continue running or remain queued. An excessively short timeout combined with frequent application retries might cause retries to overlap with unfinished requests, increasing TiKV load and worsening request buildup during a failure. If your application retries an operation, use exponential backoff with jitter to reduce the additional load on TiKV.
+
 ### tidb_dml_type <span class="version-mark">New in v8.0.0</span>
 
 > **Warning:**