Skip to content

Commit b2b35e0

Browse files
Auto-sync: Update English docs from Chinese PR
Synced from: pingcap/docs-cn#21600 Target PR: #22859 AI Provider: azure Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
1 parent e883ee2 commit b2b35e0

1 file changed

Lines changed: 20 additions & 0 deletions

File tree

system-variables.md

Lines changed: 20 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2857,6 +2857,26 @@ Assume that you have a cluster with 4 TiDB nodes and multiple TiKV nodes. In thi
28572857
- Default value: `ON`
28582858
- This variable is used to control whether to enable the statement summary feature. If enabled, SQL execution information like time consumption is recorded to the `information_schema.STATEMENTS_SUMMARY` system table to identify and troubleshoot SQL performance issues.
28592859

2860+
### `tidb_enable_strict_not_null_check` <span class="version-mark">New in v9.0.0</span>
2861+
2862+
- Scope: SESSION | GLOBAL
2863+
- Persists to cluster: Yes
2864+
- Can be set by Hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value): No
2865+
- Type: Boolean
2866+
- Default value: `ON`
2867+
- This variable controls whether TiDB performs strict validation when `NULL` values are explicitly written to `NOT NULL` columns in `INSERT` statements.
2868+
- Possible values:
2869+
- `ON`: Enables strict `NOT NULL` validation. This behavior is closer to the standard semantics of MySQL 8.0.
2870+
- In strict SQL mode, if a `NULL` value is inserted into a `NOT NULL` column, TiDB returns an error.
2871+
- In non-strict SQL mode: for single-row `INSERT` statements, if a `NULL` value is inserted into a `NOT NULL` column, TiDB returns an error; for multi-row `INSERT` statements, if a `NULL` value is inserted into a `NOT NULL` column, TiDB downgrades the error to a warning and writes the implicit default value corresponding to the column data type.
2872+
- `OFF`: Disables strict `NOT NULL` validation for compatibility with the more permissive behavior in earlier TiDB versions. When disabled, if a `NULL` value is inserted into a `NOT NULL` column, TiDB downgrades the error to a warning and writes the implicit default value corresponding to the column data type. For example, `0` is written for numeric types, and an empty string `''` is written for string types.
2873+
2874+
> **Note:**
2875+
>
2876+
> - Earlier TiDB versions were relatively permissive in validating `NOT NULL` constraints. When a `NULL` value was inserted into a `NOT NULL` column, TiDB might automatically write the implicit default value corresponding to the column data type. Starting from v8.5.0, TiDB tightened this validation: even in non-strict SQL mode, inserting a `NULL` value into a `NOT NULL` column might directly return an error. This behavior is closer to MySQL 8.0 semantics, but it might affect existing applications that depend on the earlier permissive behavior of TiDB.
2877+
>
2878+
> - If you upgrade from an earlier TiDB version to a version with strict `NOT NULL` validation enabled, and your existing business logic depends on the behavior of automatically using implicit default values after writing `NULL` to `NOT NULL` columns, related SQL statements might return errors after the upgrade. If you cannot immediately modify the business logic, you can temporarily set this variable to `OFF` to reduce upgrade compatibility risks. It is recommended to later modify the application logic to avoid explicitly writing `NULL` values to `NOT NULL` columns.
2879+
28602880
### tidb_enable_strict_double_type_check <span class="version-mark">New in v5.0</span>
28612881

28622882
- Scope: SESSION | GLOBAL

0 commit comments

Comments
 (0)