UNIQUE约束是否自动在字段上创建INDEX?

gre*_*emo 88 mysql sql indexing

我应该在列上定义一个单独的索引email(用于搜索目的),还是"自动"添加索引以及UNIQ_EMAIL_USER约束?

CREATE TABLE IF NOT EXISTS `customer` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `user_id` int(11) NOT NULL,
  `first` varchar(255) NOT NULL,
  `last` varchar(255) NOT NULL,
  `slug` varchar(255) NOT NULL,
  `email` varchar(255) NOT NULL,
  `created_at` datetime NOT NULL,
  `updated_at` datetime NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `UNIQ_SLUG` (`slug`),
  UNIQUE KEY `UNIQ_EMAIL_USER` (`email`,`user_id`),
  KEY `IDX_USER` (`user_id`)
) ENGINE=InnoDB;
Run Code Online (Sandbox Code Playgroud)

编辑:正如Corbin所建议我EXPLAIN SELECT * FROM customer WHERE email = 'address'在空桌上查询.这是结果,我不知道如何解释它:

id select_type type possible_keys key  key_len ref  rows Extra
1  SIMPLE      ALL  NULL          NULL NULL    NULL 1    Using where
Run Code Online (Sandbox Code Playgroud)

在向表中添加IXD_EMAIL时,同一查询显示:

id select_type type possible_keys key       key_len ref   rows Extra
1  SIMPLE      ref  IDX_EMAIL     IDX_EMAIL 257     const 1    Using where
Run Code Online (Sandbox Code Playgroud)

pio*_*trm 100

唯一键是索引的特殊情况,其作用类似于常规索引,并添加了对唯一性的检查.使用SHOW INDEXES FROM customer您可以看到您的唯一键实际上是B树类型索引.

(email,user_id)上的复合索引就足够了,你不需要单独的电子邮件索引 - mysql可以使用复合索引的最左边部分.可能存在一些边界情况,其中索引的大小可能会减慢查询速度,但在实际遇到它们之前,您不必担心它们.

至于测试索引使用情况,您应首先使用一些数据填充表格,以使优化器认为使用该索引实际上是值得的.

  • 它不起作用,因为电子邮件不是(user_id,email)对的最左边部分.你不能只使用最右边的部分来找到你的行. (8认同)