MySQL中一个FOREIGN列的PRIMARY和INDEX键

Question

我使用MySQL Workbench准备数据库布局，并使用phpMyAdmin将其导出到我的数据库中。在查看一个表时，我收到了以下警告：

PRIMARY和INDEX键不应同时设置为列gid。

gid是不同表的主键的外部索引，也是当前表的主键的一部分。因此，我将其作为主键的一部分，并且Workbench为外键条目创建了索引。那么为什么会出现这个警告？我应该忽略它还是应该重新考虑我的数据库布局？

这是使用的结构的一个非常简化的示例，它会产生警告：

CREATE  TABLE IF NOT EXISTS `test_groups` (
  `gid` INT NOT NULL ,
  `gname` VARCHAR(45) NULL ,
  PRIMARY KEY (`gid`) );

CREATE  TABLE IF NOT EXISTS `test_users` (
  `gid` INT NOT NULL ,
  `uid` INT NOT NULL ,
  `name` VARCHAR(45) NULL ,
  PRIMARY KEY (`gid`, `uid`) ,
  INDEX `gid` (`gid` ASC) ,
  CONSTRAINT `gid`
    FOREIGN KEY (`gid` )
    REFERENCES `test_groups` (`gid` )
    ON DELETE CASCADE
    ON UPDATE CASCADE);

编辑 我尝试在phpMyAdmin中删除gid的额外索引，看起来它可以工作。当更改组表中的内容时，级联操作仍然发生，因此我想即使没有索引，外键关系也是完整的。

但是为什么MySQL Workbench强制我保留该索引？只要有外键存在，我就无法手动删除它。

- poke

Answer 1

这没什么问题。即使它是当前表的整个主键，它仍然可能是正确的。实际上，除非你是那些只使用自增列作为主键的“程序员”中的一员，否则你会经常看到这种报告。

- symcbean

---

所以为外键创建附加索引是正确的吗？对不起，但我没有理解您答案的第二部分。 - poke

抱歉 - 我以为它对将字段同时作为主键和外键有问题。是的，第二个索引是多余的，mysql会愉快地使用主键索引来返回通过“gid”查询的行。它会稍微低效一点 - 但你永远无法测量出差异。 - symcbean

Answer 2

我现在解决了那个问题。看起来我的服务器上默认的数据库存储引擎设置为MyISAM，所以因为我没有明确指定它，所有的外键关系都被忽略了（虽然没有明确说明）。将其转换为InnoDB后，我不再收到警告，所以似乎一切都正常工作。

然而，在这种特殊情况下，我将继续使用MyISAM，并暂时将外键关系排除在外，因为我想要自动递增该多键中的第二个属性（而InnoDB不支持此功能），对于这个应用程序来说，这比拥有外键更有用（尤其是在更新和删除数据很少发生的情况下）。

另外，关于MySQL Workbench，这个行为似乎仍然有些错误，并且已经报告过了。

- poke

---

那个错误被错误地标记为另一个已修复的错误的重复。这是当前相关的错误。 - phazei