MySQL是否隐式地为UNIQUE和FOREIGN KEY约束生成索引，还是我应该显式地创建索引？

Question

Let's consider a database of 2 simple tables: tablea has an INT id , a VARCHAR something field and references tableb (containing a same field but with UNIQUE constraint added).

MySQL Workbench will generate the following code if we use it to design and forward-engineer this schema:

CREATE TABLE IF NOT EXISTS `tableb` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `something` VARCHAR(45) NULL,
  PRIMARY KEY (`id`),
  UNIQUE INDEX `something_UNIQUE` (`something` ASC))
ENGINE = InnoDB;

CREATE TABLE IF NOT EXISTS `tablea` (
  `id` INT NOT NULL,
  `something` VARCHAR(45) NULL,
  `tableb_id` INT NOT NULL,
  PRIMARY KEY (`id`, `tableb_id`),
  INDEX `fk_tablea_tableb_idx` (`tableb_id` ASC),
  CONSTRAINT `fk_tablea_tableb`
    FOREIGN KEY (`tableb_id`)
    REFERENCES `tableb` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;

but we can seemingly reach the same effect (same schema of tables, columns and constraints) with more simple, minimalistic code:

CREATE TABLE IF NOT EXISTS `tableb` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `something` VARCHAR(45) NULL,
  PRIMARY KEY (`id`),
  UNIQUE (`something`)
) ENGINE = InnoDB;

CREATE TABLE IF NOT EXISTS `tablea` (
  `id` INT NOT NULL,
  `something` VARCHAR(45) NULL,
  `tableb_id` INT NOT NULL,
  PRIMARY KEY (`id`, `tableb_id`),
  FOREIGN KEY (`tableb_id`) REFERENCES `tableb`(`id`)
) ENGINE = InnoDB;

Is the first version any way better (eg faster) than the second? Won't MySQL create the indices mentioned in the first version in the second case as well?

Answer 1

In your last chunk as I mentioned in comments and as the manual says, you do not need to explicitly create the FK-related keys in the child tables (the referencing). MySQL will auto create them for you if needed based on left-most (or first most as the manual says). A single column index is naturally left-most. For composites, that is multi-column keys, left-most naturally makes some sense.

It will be very apparent if you run your above, and issue a

show create table tablea;

If you happen to have a left-most key defined already in a child, and it is usable for the FK relationship, the engine will not create one for you on its own.

From the manual page entitled Using FOREIGN KEY Constraints

In the referencing table, there must be an index where the foreign key columns are listed as the first columns in the same order. Such an index is created on the referencing table automatically if it does not exist. This index might be silently dropped later, if you create another index that can be used to enforce the foreign key constraint. index_name, if given, is used as described previously.

Also as I mentioned in the comment section under your question, the referenced table (the parent), however, must have the necessary left-most keys in place for fast lookup prior to all of this. That key does not need to be a PRIMARY or unique key. But it must be available left-most for composites. If one is not available in the parent prior to the ALTER TABLE or CREATE TABLE of the child, then the operation fails with

MySQL Error 1215: Cannot add foreign key constraint

As for a few quick examples of when a key is created on your behalf (or not) in child tables:

1. If you explicitly create a key on col1, and it is used in an FK, a helper key is not created for you.

2. If you explicitly create a composite key on (a,b,c,d), and you have an FK on (a,b), then a helper key is not created for you.

3. If you explicitly create a composite key on (a,b,c,d), and you have an FK on (a,c), then a helper key is created for you. Because the b gets in the way on the explicit and a new key is required.

4. If you explicitly create a composite key on (a,b,c,d), and you have an FK on (a,b,c), then a helper key is not created for you. The left-most on the explicit, in the same order, was more than adequate for the requirements of the FK.