web-dev-qa-db-ja.com

UNIQUE制約は、フィールドにINDEXを自動的に作成しますか？

（別のインデックスを定義する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;

[〜＃〜] edit [〜＃〜]：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

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
mysqlsqlindexing
84
gremo

一意キーはインデックスの特殊なケースであり、一意性のチェックが追加された通常のインデックスのように機能します。 SHOW INDEXES FROM customerを使用すると、一意のキーが実際にはBツリータイプのインデックスであることがわかります。

（email、user_id）の複合インデックスで十分です。電子メールのみに個別のインデックスは必要ありません-mysqlは複合インデックスの左端の部分を使用できます。インデックスのサイズによってクエリの速度が低下する可能性のある境界ケースがありますが、実際にクエリを実行するまで心配する必要はありません。

インデックスの使用状況をテストする場合、まず、テーブルにデータを入力して、オプティマイザにそのインデックスを実際に使用する価値があると判断させる必要があります。

95
piotrm