ナビゲーション:
目次
1.2.2 外部キーの存在を確認する場合は、レコードを削除して外部キーを維持する
3.1 外部キーを使用すべきでないのはどのような状況ですか? なぜインターネット大手は外部キー制約を無効にするのでしょうか?
1. 外部キーの導入
1.1 概要
-- 创建表时添加外键约束
CREATE TABLE 表名(
列名 数据类型,
…
[CONSTRAINT] [外键取名名称] FOREIGN KEY(外键列名) REFERENCES 主表(主表列名)
);
-- 创建表时添加外键约束，constraint译作限制，束缚；references译作关联，参考，提及
create table 表名(
列名 数据类型,
…
[constraint] [外键取名名称] foreign key(外键列名) references 主表(主表列名)
); -- 建完表后添加外键约束
ALTER TABLE 表名 ADD CONSTRAINT 外键名称 FOREIGN KEY (外键字段名称) REFERENCES 主表名称(主表列名称);
-- 建完表后添加外键约束
alter table 表名 add constraint 外键名称 foreign key (外键字段名称) references 主表名称(主表列名称);-
外部キー制約を削除する
ALTER TABLE 表名 DROP FOREIGN KEY 外键名称;1.2 演習
1.2.1 データの準備
-- 删除表
DROP TABLE IF EXISTS emp;
DROP TABLE IF EXISTS dept;
-- 部门表
CREATE TABLE dept(
id int primary key auto_increment,
dep_name varchar(20),
addr varchar(20)
);
-- 员工表
CREATE TABLE emp(
id int primary key auto_increment,
name varchar(20),
age int,
dep_id int,
-- 添加外键 dep_id,关联 dept 表的id主键
CONSTRAINT fk_emp_dept FOREIGN KEY(dep_id) REFERENCES dept(id)
);データの追加
-- 添加 2 个部门
insert into dept(dep_name,addr) values
('研发部','广州'),('销售部', '深圳');
-- 添加员工,dep_id 表示员工所在的部门
INSERT INTO emp (name, age, dep_id) VALUES
('张三', 20, 1),
('李四', 20, 1),
('王五', 20, 1),
('赵六', 20, 2),
('孙七', 22, 2),
('周八', 18, 2);
1.2.2 外部キーの存在を確認する場合は、レコードを削除して外部キーを維持する
研发部この時点でこのデータを削除すると、削除できないことがわかります。
DELETE FROM dept WHERE id=1
1.2.3 外部キーがないことを確認する場合、レコードを削除しても外部キーを維持する必要はありません
外部キーを削除する
alter table emp drop FOREIGN key fk_emp_dept;研发部この時点でこのデータを削除すると、削除が成功したことがわかります。
DELETE FROM dept WHERE id=1 
1.2.3 外部キーを再度追加する
alter table emp add CONSTRAINT fk_emp_dept FOREIGN key(dep_id) REFERENCES dept(id);1.2.4 すべての外部キーをクエリする
SELECT
COLUMN_NAME,
CONSTRAINT_NAME,
REFERENCED_TABLE_NAME,
REFERENCED_COLUMN_NAME
FROM
INFORMATION_SCHEMA.KEY_COLUMN_USAGE
WHERE
TABLE_NAME = 'emp'
AND REFERENCED_TABLE_NAME IS NOT NULL;
次に、外部キーの長所と短所
2.1 外部キーの欠点
- 変更または削除する場合は、外部キーを考慮する必要があります。DELETEまたは UPDATE を実行するたびに、外部キー制約を考慮する必要がありますが、これは不便です。
- テーブル レベルのロックは同時実行性の低下につながります。同時実行性の問題により、外部キー制約により行レベルのロックが有効になります。 書き込み時にメイン テーブルがブロック状態になります。
- カスケード削除の問題:メイン テーブルのレコードを削除すると、そのレコードの外部キーに関連付けられているセカンダリ テーブルのレコードも削除され、データが制御不能になります。たとえば、「注文テーブル」の注文を削除すると、関連する「注文詳細テーブル」のレコードも削除されます。
- 結合度が高くマイグレーションが面倒：メインテーブルとスレーブテーブルが結合しているため、メインテーブルのデータ量が多すぎてテーブルを分割してデータを移行したい場合、まず外部キーを削除する必要があります。それ以外の場合は、メイン テーブルのレコードを削除し、それをスレーブ テーブルに関連付けるだけです。レコードもカスケード削除され、データが失われます。
2.2 外部キーの利点
- データの一貫性:データベースは外部キーを通じてデータの整合性と一貫性を保証できます。マスター テーブルのレコードが更新されると、スレーブ テーブルの対応するレコードも変更され、同時実行性を犠牲にしてデータの一貫性を確保するために、変更が行われるときにテーブル レベルのロックが追加されるためです。たとえば、「注文テーブル」の注文を削除すると、関連する「注文詳細テーブル」のレコードも削除されます。
- ER 図の可読性の向上:外部キーを使用すると、テーブル間の関係をより直観的に確認できます。
3. 適用可能なシナリオ
3.1 外部キーを使用すべきでないのはどのような状況ですか? なぜインターネット大手は外部キー制約を無効にするのでしょうか?
外部キーの長所と短所を総合的に比較すると、次のように結論付けることができます。
同時実行性が高く、大量のテーブル データがある分散プロジェクトは、外部キーの使用に適しています。データが更新されるたびにテーブルレベルのロックが追加されるのを防ぎ、外部キーの一貫性を維持します。
大手インターネット メーカーの製品は同時実行性が高く、一般に分散プロジェクトであるため、データベースの同時実行パフォーマンスを向上させるために、ビジネス レベルでデータの一貫性を実現するために外部キーは通常無効になっています。 「注文テーブル」では、まず「注文明細テーブル」の該当するレコードを関連付けて、1件ずつ削除していきます。
3.2 外部キーはどのような状況で使用できますか?
外部キーの長所と短所を総合的に比較すると、次のように結論付けることができます。
同時実行性が低く、テーブル データ量が小さく、データ整合性要件が高いモノリシック プロジェクトは、外部キーの使用に適しています。