这些 FK 定义是否等效？答案

【问题标题】：Are these FK definitions equivalent?这些 FK 定义是否等效？
【发布时间】：2019-10-11 16:30:57
【问题描述】：

address 的以下两个外键定义是否等效？我的意思是它们最终是否具有相同的有效数据库元素（索引、约束等）。我更喜欢后者，因为它是一种简写形式，而且输入起来也比较少。

这里显式创建了地址索引和约束：

CREATE TABLE customer (
  customer_id SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT,
  first_name VARCHAR(45) NOT NULL,
  last_name VARCHAR(45) NOT NULL,
  PRIMARY KEY  (customer_id),
  KEY idx_fk_address_id (address_id),
  CONSTRAINT fk_customer_address FOREIGN KEY (address_id) REFERENCES address (address_id) ON DELETE RESTRICT ON UPDATE CASCADE
)ENGINE=InnoDB DEFAULT CHARSET=utf8;

这里是否也创建了约束和索引？

CREATE TABLE customer (
  customer_id SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT,
  first_name VARCHAR(45) NOT NULL,
  last_name VARCHAR(45) NOT NULL,
  PRIMARY KEY  (customer_id),
  FOREIGN KEY (address_id) REFERENCES address (address_id) ON DELETE RESTRICT ON UPDATE CASCADE
)ENGINE=InnoDB DEFAULT CHARSET=utf8;

还有其他需要注意的区别吗？

【问题讨论】：

我更喜欢命名约束，当您需要禁用或删除它时更易于维护。
难道你没有按约定隐式生成一个你也可以禁用的约束名称吗？
是的，你会得到自动生成的名字，但是你需要读取元数据表。其次，当您使用模式比较软件并且数据库是从头开始设置的第二次时，它可以将其显示为差异（取决于选项）。显式优于隐式。
只有 65000 个客户？快点;你的野心在哪里！！
@Strawberry LOL :D

标签： mysql sql foreign-keys schema ddl

【解决方案1】：

从功能的角度来看，这些声明是等价的。不同的是，第一个 sn -p 设置了一个友好的名称，以后更容易维护，第二个会创建一些自动生成的名称。

【讨论】：