mysql - 索引 FK 和索引列之间的性能和模型差异

Question

我正在设计一些表，使用 MySQL WorkBench，并在一些列上设置外键，以遵循一些“正确”的设计模式。然后，我的老板问我为什么使用 FK，因为它们“只会造成问题”。

查看 MySQL WorkBench 在创建新 FK 时做了什么，它创建了关系，并在其上创建了索引。像这样:

CREATE TABLE `smx_portales-des`.`A1` (
  `idA1` INT NOT NULL,
  `name` VARCHAR(45) NULL,
  PRIMARY KEY (`idA1`));

CREATE TABLE `smx_portales-des`.`A2` (
  `idA2` INT NOT NULL,
  `price` DECIMAL(10,2) NULL,
  `fkA1` INT NULL,
  PRIMARY KEY (`idA2`),
  INDEX `fk_A2_A1_idx` (`fkA1` ASC),
      CONSTRAINT `fk_A2_A1`
  FOREIGN KEY (`fkA1`)
      REFERENCES `smx_portales-des`.`A1` (`idA1`)
  ON DELETE NO ACTION
  ON UPDATE NO ACTION);

我的老板告诉我创建表 A2 如下:

  CREATE TABLE `smx_portales-des`.`A2` (
      `idA2` INT NOT NULL,
      `price` DECIMAL(10,2) NULL,
      `fkA1` INT NULL,
      PRIMARY KEY (`idA2`),
      INDEX fk_A2_A1(fkA1));

那么，除了 FK 的明显限制，即只允许另一个表上的值或 NULL 之外，这些模型是否还有其他性能、造型师或任何差异？

编辑:我知道 FK 有助于数据库数据完整性，并且有一些级联选项有助于删除/更新子项。此外，不同之处在于，在第二个模型中，我在“模拟”FK 列中使用索引。我想知道更多关于这两种模型的合理差异的地方，比如效率、尺寸......

Answer 1

你的老板错了。并随时向他或她展示这个答案。

关系数据库的一项关键功能是维护数据完整性。数据完整性的一个关键部分是确保外键关系正确。

在您的数据库中，这保证 a2.fka1 始终引用 a1 中的有效列(或具有 NULL 值) .这对于理解数据的人、编写查询的人(因此行不会在连接中无意中丢失)以及潜在的优化器来说都很重要。

维护此功能的正确位置是在数据库中。您可以尝试从应用程序中执行此操作，但无论数据修改操作如何，数据库都会确保数据正确。

最后，外键非常灵活。您(和您的老板)应该了解级联约束。它们通常实现应用程序所需的功能。