MySQL无法删除外键约束中所需的索引

Question

我需要更改现有数据库以添加列.因此,我还想更新UNIQUE字段以包含该新列.我正在尝试删除当前索引,但一直收到错误MySQL Cannot drop index needed in a foreign key constraint

CREATE TABLE mytable_a (
ID          TINYINT NOT NULL AUTO_INCREMENT PRIMARY KEY,
Name        VARCHAR(255) NOT NULL,
UNIQUE(Name)
) ENGINE=InnoDB;

CREATE TABLE mytable_b (
ID          TINYINT NOT NULL AUTO_INCREMENT PRIMARY KEY,
Name        VARCHAR(255) NOT NULL,
UNIQUE(Name)
) ENGINE=InnoDB;

CREATE TABLE mytable_c (
ID          TINYINT NOT NULL AUTO_INCREMENT PRIMARY KEY,
Name        VARCHAR(255) NOT NULL,
UNIQUE(Name)
) ENGINE=InnoDB;


CREATE TABLE `mytable` (
  `ID` int(11) NOT NULL AUTO_INCREMENT,
  `AID` tinyint(5) NOT NULL,
  `BID` tinyint(5) NOT NULL,
  `CID` tinyint(5) NOT NULL,
  PRIMARY KEY (`ID`),
  UNIQUE KEY `AID` (`AID`,`BID`,`CID`),
  KEY `BID` (`BID`),
  KEY `CID` (`CID`),
  CONSTRAINT `mytable_ibfk_1` FOREIGN KEY (`AID`) REFERENCES `mytable_a` (`ID`) ON DELETE CASCADE,
  CONSTRAINT `mytable_ibfk_2` FOREIGN KEY (`BID`) REFERENCES `mytable_b` (`ID`) ON DELETE CASCADE,
  CONSTRAINT `mytable_ibfk_3` FOREIGN KEY (`CID`) REFERENCES `mytable_c` (`ID`) ON DELETE CASCADE
) ENGINE=InnoDB;




mysql> ALTER TABLE mytable DROP INDEX AID;
ERROR 1553 (HY000): Cannot drop index 'AID': needed in a foreign key constraint

Answer 1

你必须删除外键.MySQL中的外键自动在表上创建索引(关于该主题有一个SO问题).

ALTER TABLE mytable DROP FOREIGN KEY mytable_ibfk_1 ; 

Answer 2

步骤1

列出外键(注意它与索引名称不同)

SHOW CREATE TABLE  <Table Name>

结果将显示外键名称.

第2步

删除(外键/主键/键)键

CONSTRAINT `FOREIGN_KEY_NAME` FOREIGN KEY (`FOREIGN_KEY_COLUMN`) REFERENCES `FOREIGN_KEY_TABLE` (`id`),

第3步

删除索引.

Answer 3

如果你的意思是你可以这样做:

CREATE TABLE mytable_d (
ID          TINYINT NOT NULL AUTO_INCREMENT PRIMARY KEY,
Name        VARCHAR(255) NOT NULL,
UNIQUE(Name)
) ENGINE=InnoDB;


ALTER TABLE mytable
ADD COLUMN DID tinyint(5) NOT NULL,
ADD CONSTRAINT mytable_ibfk_4 
      FOREIGN KEY (DID) 
        REFERENCES mytable_d (ID) ON DELETE CASCADE;

 > OK.

但是之后:

ALTER TABLE mytable
DROP KEY AID ;

给出错误.

您可以删除索引并在一个ALTER TABLE语句中创建一个新索引:

ALTER TABLE mytable
DROP KEY AID ,
ADD UNIQUE KEY AID (AID, BID, CID, DID);

Answer 4

因为你必须在外键字段上有一个索引,你可以在字段'AID'上创建一个简单的索引

CREATE INDEX aid_index ON mytable (AID);

然后才删除唯一索引'AID'

ALTER TABLE mytable DROP INDEX AID;

Answer 5

对此事的更深入了解不仅有助于找到相关错误的解决方法，而且有助于更好地设计我们的表和索引。现有的一些答案是好的，但其他答案不完整或明显错误，这对于仓促的读者来说可能是危险的。

重要的初始注释

• 问题是关于UNIQUE索引的，但这在这里并不重要。重要的是感兴趣的索引是复合的（即它由 2 个以上的列组成）。
• 在 MySQL 中KEY（至少在这种情况下）是INDEX.

问题

在 MySQL 中，每个外键约束 (FKC) 都需要一个索引。并非所有 DBMS 都有这样的要求，但在实践中，如果没有这样的索引，则某些操作（例如删除从其他表引用的表中的记录）可能会遭受糟糕的性能（如果引用的表很大）足够的。这就是为什么对于像 MySQL 这样的一些 RDBM，需要这样的索引是一个经过深思熟虑的设计决定。

当我们创建 FKC 时，通常，MySQL 会自动创建一个与 FK 具有相同列的新索引（请记住，主键和外键可以包含 2 个以上的列，但在 OP 的示例中不是）。然而，如果已经存在可用于FKC的索引，MySQL将不会创建另一个索引。

在OP的例子中，如果我们不计算主键索引，我们有3个索引：AID, BID, CID。第一个是复合的，其他不是。请注意，唯一索引的名称可能有点误导，因为它与第一列的名称相同。我总是建议为复合索引提供明确的名称，以避免潜在的混淆。因此，让我们想象一下 UNIQUE KEY 的名称ABC，看看表在起始点有哪些索引：

UNIQUE KEY `ABC` (`AID`,`BID`,`CID`),
       KEY `BID` (`BID`),
       KEY `CID` (`CID`),

该密钥ABC 可用于 上的 FKC AID，因为AID是其中的第一列。这就是为什么 MySQL 决定不在only上创建额外的索引AID。但是为了满足始终拥有索引的要求而删除 MySQL 内部使用的索引是一个禁忌。因此出现了错误。

解决方案

我们应该首先问自己：我们是否想要一个明确的专用索引AID，或者我们是否想要继续使用我们现有的复合索引。根据我们的需要，两者都是有效的选择。如果我们希望仅在查询时获得最佳性能AID，那么拥有一个单独的索引可能会稍微更高效，但这会带来多一个索引的成本（更多存储、更慢更新等）。通常，使用复合索引的优点大于缺点，但是当性能至关重要时，至少知道可以选择使用较小的专用索引可能会很有用。

选项 1：为 FKC 建立（永久）专用索引

首先，我们为FKC创建专用索引：

CREATE INDEX IDX_AID ON mytable(AID);

请注意，我IDX_AID在这里使用了名称，但如果我们更愿意坚持 MySQL 命名此类索引的方式，AID则也可以使用（如果此时可用）。在我的例子中，ABC它会是，但在OP的情况下，它不会（尽管RENAME INDEX这可以很容易地解决）。

然后我们用新列重新创建唯一索引（假设NEW_COL我们希望它位于中间的某个位置/记住，索引中的列顺序很重要/）：

DROP INDEX ABC ON mytable;
CREATE UNIQUE INDEX IDX_ABNC ON mytable(AID, BID, NEW_COL, CID);

现在SHOW CREATE TABLE mytable我们应该有：

UNIQUE KEY `IDX_ABNC` (`AID`,`BID`,`NEW_COL`,`CID`),
       KEY `IDX_AID`  (`AID`),
       KEY `BID`      (`BID`),
       KEY `CID`      (`CID`),

选项 2：FKC 没有专用索引

我们本质上需要一种解决方法，以避免暂时不一致的状态。

方法1：FKC上的临时索引（首选）

这与选项 1类似，但我们只是删除最后的索引：

CREATE INDEX IDX_TMP ON mytable(AID);
DROP INDEX IDX_ABC ON mytable;  -- here we have IDX_TMP, so no problem
CREATE UNIQUE INDEX IDX_ABNC ON mytable(AID, BID, NEW_COL, CID);
DROP INDEX IDX_TMP ON mytable;  -- not needed anymore

方法2：删除FKC然后重新创建

本质上，这个想法是首先暂时删除“守卫”（即 FKC），并在最后重新创建它。

ALTER TABLE mytable DROP FOREIGN KEY <FKC-name>;    
DROP INDEX IDX_ABC ON mytable;  -- no "guard" here to stop us
CREATE UNIQUE INDEX IDX_ABNC ON mytable(AID, BID, NEW_COL, CID);
ALTER TABLE mytable ADD CONSTRAINT <FKC-name> FOREIGN KEY (AID) REFERENCES mytable(AID) ON DELETE CASCADE;

您可以找到<FKC-name>来自SHOW CREATE TABLE mytable.

推荐

我认为方法1更可取，原因如下：

• 稍微简单一些（无需查找确切的 FKC 名称）。
• 删除 FKC，即使时间很短，也会为某人插入无效值打开窗口。
• 重新创建 FKC 时存在混淆某些内容的潜在风险。例如，您可能忘记添加重要属性（例如ON DELETE CASCADE）。或者，不小心放错了。
• 如果由于某种原因，我们忘记或未能执行最后一步，使用方法 1不会造成任何损害，而使用方法 2会使数据库处于易受攻击的状态。

Answer 6

我认为这是删除索引的简单方法。

set FOREIGN_KEY_CHECKS=0; //disable checks

ALTER TABLE mytable DROP INDEX AID;

set FOREIGN_KEY_CHECKS=1; //enable checks

Answer 7

外键始终需要索引。如果没有索引，则约束将要求对引用表中的每个插入或更新的键对引用表进行全表扫描。这会对性能造成不可接受的影响。这具有以下两个后果：

• 创建外键时，数据库将检查索引是否存在。如果不是，将创建索引。默认情况下，它将与约束具有相同的名称。
• 如果只有一个索引可用于外键，则不能将其删除。如果您确实不想删除它，则必须删除外键约束或首先为其创建另一个索引。