外鍵約束命名受以下規則約束

在 FOREIGN KEY ... REFERENCES 子句中的資料表和欄位識別符可以使用反引號 ( `) 引起來。或者，如果啟用 ANSI_QUOTES SQL 模式，則可以使用雙引號 ( ")。也會考量 lower_case_table_names 系統變數設定。

外鍵約束受以下條件和限制約束

如需有關 MySQL 外鍵約束實作與 SQL 標準的差異的資訊，請參閱第 1.7.2.3 節，「FOREIGN KEY 約束差異」。

當 UPDATE 或 DELETE 作業影響父資料表中的鍵值時，如果子資料表中有相符的列，則結果取決於 FOREIGN KEY 子句的 ON UPDATE 和 ON DELETE 子句指定的參照動作。參照動作包括

對於支援外鍵的儲存引擎，如果子資料表中嘗試建立的外鍵值在父資料表中沒有匹配的候選鍵值，MySQL 會拒絕任何 INSERT 或 UPDATE 操作。

對於未指定的 ON DELETE 或 ON UPDATE，預設動作始終為 NO ACTION。

作為預設值，明確指定的 ON DELETE NO ACTION 或 ON UPDATE NO ACTION 子句不會出現在 SHOW CREATE TABLE 輸出中，也不會出現在使用 mysqldump 傾印的資料表中。RESTRICT 是一個等效的非預設關鍵字，它會出現在 SHOW CREATE TABLE 輸出中，也會出現在使用 mysqldump 傾印的資料表中。

對於 NDB 資料表，當參考對象是父資料表的主鍵時，不支援 ON UPDATE CASCADE。

對於 NDB 資料表，當子資料表包含一或多個 TEXT 或 BLOB 類型欄位時，不支援 ON DELETE CASCADE。(錯誤 #89511, 錯誤 #27484882)

InnoDB 使用深度優先搜尋演算法，對應於外鍵約束的索引記錄執行級聯操作。

儲存的產生欄位上的外鍵約束不能使用 CASCADE、SET NULL 或 SET DEFAULT 作為 ON UPDATE 參照動作，也不能使用 SET NULL 或 SET DEFAULT 作為 ON DELETE 參照動作。

儲存的產生欄位的基礎欄位上的外鍵約束不能使用 CASCADE、SET NULL 或 SET DEFAULT 作為 ON UPDATE 或 ON DELETE 參照動作。

這個簡單的範例透過單一欄位外鍵關聯 parent 和 child 資料表

CREATE TABLE parent (
    id INT NOT NULL,
    PRIMARY KEY (id)
) ENGINE=INNODB;

CREATE TABLE child (
    id INT,
    parent_id INT,
    INDEX par_ind (parent_id),
    FOREIGN KEY (parent_id)
        REFERENCES parent(id)
        ON DELETE CASCADE
) ENGINE=INNODB;

這是一個更複雜的範例，其中 product_order 資料表有另外兩個資料表的外鍵。其中一個外鍵參照 product 資料表中一個兩欄位的索引。另一個外鍵參照 customer 資料表中一個單一欄位的索引

CREATE TABLE product (
    category INT NOT NULL, id INT NOT NULL,
    price DECIMAL,
    PRIMARY KEY(category, id)
)   ENGINE=INNODB;

CREATE TABLE customer (
    id INT NOT NULL,
    PRIMARY KEY (id)
)   ENGINE=INNODB;

CREATE TABLE product_order (
    no INT NOT NULL AUTO_INCREMENT,
    product_category INT NOT NULL,
    product_id INT NOT NULL,
    customer_id INT NOT NULL,

    PRIMARY KEY(no),
    INDEX (product_category, product_id),
    INDEX (customer_id),

    FOREIGN KEY (product_category, product_id)
      REFERENCES product(category, id)
      ON UPDATE CASCADE ON DELETE RESTRICT,

    FOREIGN KEY (customer_id)
      REFERENCES customer(id)
)   ENGINE=INNODB;

您可以使用以下 ALTER TABLE 語法，將外鍵約束新增至現有的資料表

ALTER TABLE tbl_name
    ADD [CONSTRAINT [symbol]] FOREIGN KEY
    [index_name] (col_name, ...)
    REFERENCES tbl_name (col_name,...)
    [ON DELETE reference_option]
    [ON UPDATE reference_option]

外鍵可以是自我參照 (參照同一個資料表)。當您使用 ALTER TABLE 將外鍵約束新增至資料表時，請記得先在以外鍵參照的欄位上建立索引。

您可以使用以下 ALTER TABLE 語法捨棄外鍵約束

ALTER TABLE tbl_name DROP FOREIGN KEY fk_symbol;

如果您在建立約束時，FOREIGN KEY 子句定義了 CONSTRAINT 名稱，您可以使用該名稱來捨棄外鍵約束。否則，會自動產生一個約束名稱，您必須使用該值。若要判斷外鍵約束名稱，請使用 SHOW CREATE TABLE

mysql> SHOW CREATE TABLE child\G
*************************** 1. row ***************************
       Table: child
Create Table: CREATE TABLE `child` (
  `id` int DEFAULT NULL,
  `parent_id` int DEFAULT NULL,
  KEY `par_ind` (`parent_id`),
  CONSTRAINT `child_ibfk_1` FOREIGN KEY (`parent_id`)
  REFERENCES `parent` (`id`) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

mysql> ALTER TABLE child DROP FOREIGN KEY `child_ibfk_1`;

在同一個 ALTER TABLE 陳述式中新增和捨棄外鍵，支援 ALTER TABLE ... ALGORITHM=INPLACE。不支援 ALTER TABLE ... ALGORITHM=COPY。

在 MySQL 中，InnoDB 和 NDB 資料表支援外鍵約束的檢查。外鍵檢查是由 foreign_key_checks 變數控制，預設為啟用。通常，您會在正常操作期間保持此變數啟用，以強制執行參照完整性。foreign_key_checks 變數對於 NDB 資料表的作用與對 InnoDB 資料表的作用相同。

foreign_key_checks 變數是動態的，並支援全域和工作階段範圍。如需使用系統變數的相關資訊，請參閱第 7.1.9 節「使用系統變數」。

在以下情況下，停用外鍵檢查很有用

當 foreign_key_checks 停用時，會忽略外鍵約束，但以下例外情況除外

停用 foreign_key_checks 還具有以下其他含義

MySQL 會根據需要將中繼資料鎖延伸至透過外鍵約束相關聯的資料表。延伸中繼資料鎖可防止相關資料表上同時執行衝突的 DML 和 DDL 操作。此功能還可在修改父資料表時，更新外鍵中繼資料。在較早的 MySQL 版本中，由子資料表擁有的外鍵中繼資料無法安全地更新。

如果使用 LOCK TABLES 明確鎖定資料表，則會隱含地開啟和鎖定透過外鍵約束相關聯的任何資料表。對於外鍵檢查，會對相關資料表進行共用唯讀鎖定 (LOCK TABLES READ)。對於級聯更新，會對操作中涉及的相關資料表進行共用無寫入鎖定 (LOCK TABLES WRITE)。

若要檢視外鍵定義，請使用 SHOW CREATE TABLE

mysql> SHOW CREATE TABLE child\G
*************************** 1. row ***************************
       Table: child
Create Table: CREATE TABLE `child` (
  `id` int DEFAULT NULL,
  `parent_id` int DEFAULT NULL,
  KEY `par_ind` (`parent_id`),
  CONSTRAINT `child_ibfk_1` FOREIGN KEY (`parent_id`)
  REFERENCES `parent` (`id`) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

您可以從 Information Schema KEY_COLUMN_USAGE 資料表取得外鍵的相關資訊。以下顯示針對此資料表查詢的範例

mysql> SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME, CONSTRAINT_NAME
       FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE
       WHERE REFERENCED_TABLE_SCHEMA IS NOT NULL;
+--------------+------------+-------------+-----------------+
| TABLE_SCHEMA | TABLE_NAME | COLUMN_NAME | CONSTRAINT_NAME |
+--------------+------------+-------------+-----------------+
| test         | child      | parent_id   | child_ibfk_1    |
+--------------+------------+-------------+-----------------+

您可以從 INNODB_FOREIGN 和 INNODB_FOREIGN_COLS 資料表取得特定於 InnoDB 外鍵的資訊。以下顯示查詢範例

mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_FOREIGN \G
*************************** 1. row ***************************
      ID: test/child_ibfk_1
FOR_NAME: test/child
REF_NAME: test/parent
  N_COLS: 1
    TYPE: 1

mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_FOREIGN_COLS \G
*************************** 1. row ***************************
          ID: test/child_ibfk_1
FOR_COL_NAME: parent_id
REF_COL_NAME: id
         POS: 0

如果發生與 InnoDB 資料表相關的外鍵錯誤 (通常是 MySQL Server 中的錯誤 150)，可以透過檢查 SHOW ENGINE INNODB STATUS 輸出來取得有關最新外鍵錯誤的資訊。

mysql> SHOW ENGINE INNODB STATUS\G
...
------------------------
LATEST FOREIGN KEY ERROR
------------------------
2018-04-12 14:57:24 0x7f97a9c91700 Transaction:
TRANSACTION 7717, ACTIVE 0 sec inserting
mysql tables in use 1, locked 1
4 lock struct(s), heap size 1136, 3 row lock(s), undo log entries 3
MySQL thread id 8, OS thread handle 140289365317376, query id 14 localhost root update
INSERT INTO child VALUES (NULL, 1), (NULL, 2), (NULL, 3), (NULL, 4), (NULL, 5), (NULL, 6)
Foreign key constraint fails for table `test`.`child`:
,
  CONSTRAINT `child_ibfk_1` FOREIGN KEY (`parent_id`) REFERENCES `parent` (`id`) ON DELETE
  CASCADE ON UPDATE CASCADE
Trying to add in child table, in index par_ind tuple:
DATA TUPLE: 2 fields;
 0: len 4; hex 80000003; asc     ;;
 1: len 4; hex 80000003; asc     ;;

But in parent table `test`.`parent`, in index PRIMARY,
the closest match we can find is record:
PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 4; hex 80000004; asc     ;;
 1: len 6; hex 000000001e19; asc       ;;
 2: len 7; hex 81000001110137; asc       7;;
...