Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 4 additions & 2 deletions foreign-key.md
Original file line number Diff line number Diff line change
Expand Up @@ -177,9 +177,11 @@ When the foreign key constraint check is disabled, the foreign key constraint ch

## Locking

When `INSERT` or `UPDATE` a child table, the foreign key constraint checks whether the corresponding foreign key value exists in the parent table, and locks the row in the parent table to avoid the foreign key value being deleted by other operations violating the foreign key constraint. The locking behavior is equivalent to performing a `SELECT FOR UPDATE` operation on the row where the foreign key value is located in the parent table.
When you `INSERT` into or `UPDATE` a child table, the foreign key constraint checks whether the corresponding foreign key value exists in the parent table and locks the row in the parent table to prevent other operations from deleting the foreign key value and violating the foreign key constraint.

Because TiDB currently does not support `LOCK IN SHARE MODE`, if a child table accepts a large number of concurrent writes and most of the referenced foreign key values are the same, there might be serious locking conflicts. It is recommended to disable [`foreign_key_checks`](/system-variables.md#foreign_key_checks) when writing a large number of child table data.
By default, the locking behavior of foreign key checks is equivalent to performing a `SELECT FOR UPDATE` operation (exclusive lock) on the row where the foreign key value is located in the parent table. In concurrent write scenarios for a child table, if most of the referenced foreign key values are the same, there might be serious locking conflicts.

You can enable the system variable [`tidb_foreign_key_check_in_shared_lock`](/system-variables.md#tidb_foreign_key_check_in_shared_lock-new-in-v856-and-v900) to let foreign key checks use shared locks. Shared locks allow multiple transactions to hold locks on the same row simultaneously, reducing lock conflicts and improving the performance of concurrent writes to child tables.

## Definition and metadata of foreign keys

Expand Down
9 changes: 9 additions & 0 deletions system-variables.md
Original file line number Diff line number Diff line change
Expand Up @@ -3147,6 +3147,15 @@ For a system upgraded to v5.0 from an earlier version, if you have not modified
>
> Starting from v6.6.0, TiDB supports [Resource Control](/tidb-resource-control-ru-groups.md). You can use this feature to execute SQL statements with different priorities in different resource groups. By configuring proper quotas and priorities for these resource groups, you can gain better scheduling control for SQL statements with different priorities. When resource control is enabled, statement priority will no longer take effect. It is recommended that you use [Resource Control](/tidb-resource-control-ru-groups.md) to manage resource usage for different SQL statements.

### tidb_foreign_key_check_in_shared_lock <span class="version-mark">New in v8.5.6 and v9.0.0</span>

- Scope: SESSION | GLOBAL
- Persists to cluster: Yes
- Applies to hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value): No
- Type: Boolean
- Default value: `OFF`
- This variable controls whether foreign key checks in pessimistic transactions use shared locks instead of exclusive locks. When enabled, foreign key checks acquire shared locks on rows in the parent table, allowing multiple concurrent transactions to validate the same parent row without blocking each other. This behavior improves the performance of concurrent writes to child tables.

### tidb_gc_concurrency <span class="version-mark">New in v5.0</span>

> **Note:**
Expand Down
Loading