MySQLのプライマリ・キーと外部キーの区別と連絡

主キーと外キーの関係は、一般的に言えば、私は今フォーラムを持っていて、2枚の表があって、1枚は主貼threadで、1枚はレスreplyです
まず、プライマリ・キーといえば、プライマリ・キーはテーブル内の唯一の識別レコードのフィールドであり、一般的には投稿idであり、アクセス時、例えばthread.php?id=1私がアクセスするのは投稿idが1の投稿であることを示します～
また、外部キーについては、投稿を削除するときに別の操作を実行する必要があります.つまり、すべての投稿を削除する必要があります.通常、delete操作(threadとreply)を2回実行する必要があります.この場合、外部キーが存在する場合、例えば、replyテーブルの裏面にthreadテーブルを指すプライマリキー(id)の外部キー(この外部キーが縛られているフィールドは、投稿に対応するidでなければなりません)を作成し、応答deleteを指定します.threadを削除するとき、mysqlは自分でreplyテーブルのこの投稿の返事を削除して、手動でreplyテーブルのdelete操作をもう一度実行する必要はありません.
両者の関係については,先の例ではreplyテーブルの外部キーがthreadテーブルのプライマリキーを指す〜
例を作って、簡単に使って、dageとxiaodiの2つの表をして、長兄の表は主な鍵で、弟の表は外の鍵です:表を建てます:

CREATE TABLE `dage` (
 `id` int(11) NOT NULL auto_increment,
 `name` varchar(32) default '',
 PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1；

CREATE TABLE `xiaodi` (
 `id` int(11) NOT NULL auto_increment,
 `dage_id` int(11) default NULL,
 `name` varchar(32) default '',
 PRIMARY KEY (`id`),
 KEY `dage_id` (`dage_id`),
 CONSTRAINT `xiaodi_ibfk_1` FOREIGN KEY (`dage_id`) REFERENCES `dage` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1；

兄貴を挿入:

mysql> insert into dage(name) values('   ');

Query OK, 1 row affected (0.01 sec)

mysql> select * from dage;

+----+--------+
| id | name  |
+----+--------+
| 1 |     |
+----+--------+
1 row in set (0.00 sec)

弟を挿入:

mysql> insert into xiaodi(dage_id,name) values(1,'   _  A');

Query OK, 1 row affected (0.02 sec)

mysql> select * from xiaodi;

+----+---------+--------------+
| id | dage_id | name     |
+----+---------+--------------+
| 1 |    1 |    _  A |
+----+---------+--------------+

兄貴を削除:

mysql> delete from dage where id=1;

ERROR 1451 (23000): Cannot delete or update a parent row: a foreign key constraint fails (`bstar/xiaodi`, CONSTRAINT `xiaodi_ibfk_1` FOREIGN KEY (`dage_id`) REFERENCES `dage` (`id`))

ヒント:だめだよ.約束があるんだよ.お兄さんの下に弟がいるんだから、放っておくわけにはいかないよ.
新しい弟を挿入します.

mysql> insert into xiaodi(dage_id,name) values(2,'  _  A');   

2ERROR 1452 (23000): Cannot add or update a child row: a foreign key constraint fails (`bstar/xiaodi`, CONSTRAINT `xiaodi_ibfk_1` FOREIGN KEY (`dage_id`) REFERENCES `dage` (`id`))

ヒント:小僧、造反したいんだよ.君はまだ兄貴がいないよ.
外部キー制約をイベントトリガ制限に追加するには、次の手順に従います.

mysql> show create table xiaodi;

CONSTRAINT `xiaodi_ibfk_1` FOREIGN KEY (`dage_id`) REFERENCES `dage` (`id`)
mysql> alter table xiaodi drop foreign key xiaodi_ibfk_1;

Query OK, 1 row affected (0.04 sec)
Records: 1 Duplicates: 0 Warnings: 

mysql> alter table xiaodi add foreign key(dage_id) references dage(id) on delete cascade on update cascade;

Query OK, 1 row affected (0.04 sec)
Records: 1 Duplicates: 0 Warnings: 0

もう一度お兄さんを削除してみました.

mysql> delete from dage where id=1;

Query OK, 1 row affected (0.01 sec)

mysql> select * from dage;

Empty set (0.01 sec)

mysql> select * from xiaodi;

Empty set (0.00 sec)

はい、今度は対応する弟もいません.仕方がありません.誰が私にon delete cascadeをさせましたか.
例の说明ははっきりしているでしょう.他の机能対応マニュアルは自分で実践しましょう.
データベースの設計時に外部キーを使用するかどうかについては、次のような問題があります.
外部キーが使用されているかどうかは、ビジネスアプリケーションのシーンや開発コストを見て、いつ適用され、いつ適用されないかを大まかに列挙します.
1.インターネット業界の応用は外部キーの使用を推奨しない:ユーザー量が大きく、同時度が高いため、データベースサーバーは性能のボトルネックになりやすく、特にIO能力に制限され、簡単にレベルを拡張できない.データ整合性の制御をトランザクションに置くと、アプリケーションサーバにこの部分の圧力を負わせるが、リファレンスサーバは一般的に簡単に水平に伸縮できる.
2.伝統的な業界1>.ソフトウェアアプリケーションの人数は限られており、言い換えれば制御可能である.2>.データベース・サーバのデータ量も一般的には大きくなく、アクティブなデータは限られています.
上記2つの文の説明を総合すると、すなわちデータベースサーバの性能は問題ではないので、性能の問題をあまり考慮する必要はありません.また、外部キーを使用すると開発コストを削減でき、データベース製品自体のトリガによってテーブルと関連テーブル間のデータ整合性と更新を実現することができる.最後に、外部キーを使用する方法では、開発者とデータベース設計者の分業を行うことができ、プログラマーのためにより多くの作業量を負担することができます.外部キーのパフォーマンスに問題がある理由:
1.データベースは外部キーの内部管理を維持する必要がある;
2.外部キーはデータの一貫性トランザクションを実現することに等しく、すべてデータベースサーバに渡して完成する.
3.外部キーがあれば、外部キーフィールドの増加、削除、更新操作に関連するいくつかの操作として、関連操作をトリガして検査し、資源を消費しなければならない.
4.外部キーは、他のテーブルの内部ロックを要求する必要があるため、デッドロックが発生しやすい.
作者:mysqlops
リンク:https://www.zhihu.com/question/19600081/answer/13295957
出典:知っている