假设我们有一个用户表：
+---------+----------+------------+------------+----------------+
| Surname | Forename | ZIP | DOB | Email |
+---------+----------+------------+------------+----------------+
| Jones | John | 60612-0344 | 1970-02-14 | [email protected] |
| Jones | Jane | 60612-0344 | 1971-05-26 | [email protected] |
| Smith | Sara | 19002-0052 | 1982-06-21 | [email protected] |
+---------+----------+------------+------------+----------------+
因为我们的应用程序要求每个用户都有自己不同的电子邮件地址，所以我们可以通过Email柱：它形成一个key到表中。此类键（在单个列上定义）被认为是simple.
在某些情况下，人们可能知道没有两个用户可以具有相同的姓名、出生日期和邮政编码：那么另一个可能的密钥将是以下组合(Surname, Forename, ZIP, DOB)。这样的键（在多个列上定义）被认为是合成的.
由于每条记录的键（根据定义）必须是唯一的，因此可以告诉 MySQL 通过定义一个UNIQUE相关列的索引（表的PRIMARY KEY是一种特殊类型UNIQUE索引）：尝试创建（或更新）与现有记录具有相同键的记录将失败。
现在假设有一张订单表：
+--------------+-----------+---------+----------+
| Order_number | Status | Total | Customer |
+--------------+-----------+---------+----------+
| 12345 | Completed | 1234.99 | ? |
| 12346 | Pending | 345.00 | ? |
| 12347 | Cancelled | 9876.50 | ? |
+--------------+-----------+---------+----------+
我们希望将订单与用户表中的相关记录关联起来。但如何做到这一点呢？我们在里面放什么Customer column?
显然，我们希望标识 users 表中的唯一记录，因此我们需要使用它的键之一（例如Email在上面的第一个例子中）。以这种方式使用一个表的键从另一个表引用其记录在关系数据库中非常常见：在这种情况下，我们将引用列称为外键（因为它保存了外部表的键）。
如果我们使用复合键作为参考，我们将有一个复合外键。在上面的第二个示例中，我们的订单表可能包含列Customer_Surname, Customer_Forename, Customer_ZIP and Customer_DOB这将共同形成用户表的外键（在这种情况下，我不推荐这样的模式）。
MySQL不仅可以强制外键约束（确保引用的记录存在于外表中），但如果引用的记录本身被更新或删除，也可以自动更新或删除引用（订单）表。例如，如果 John 从 users 表中删除，则他的所有订单都会自动从orders 表中清除（同样，在这种情况下可能不是人们想要的）；或者如果他的电子邮件地址发生变化，Customer列可以自动更新。
