在哪些情況下，我應該爲多個列創建一個索引，而不是爲每個列創建單獨的索引？

Question

在哪些情況下，我應該爲多列創建一個索引，而不是爲每列創建單獨的索引？

Answer 1

如果您查詢的條件包含多列。如果您將所有列形式條件添加到索引。你會加速執行。使用EXPLAIN命令在添加索引之前和之後檢查執行計劃。當然，不要添加太多列，尤其是不同類型的列，因爲添加索引可能沒有好處。

Answer 2

綜合指數將有助於大多數情況。如果你有一個像下面那樣的桌子。

請考慮下表。

用戶

+-----------+--------------+------+-----+---------+-------+ 
| Field  | Type   | Null | Key | Default | Extra | 
+-----------+--------------+------+-----+---------+-------+ 
| ID  | int(11)  | YES |  | NULL |  | 
| USER  | varchar(100) | YES |  | NULL |  | 
| EMAIL_ID | varchar(200) | YES |  | NULL |  | 
| MODE  | varchar(50) | YES |  | NULL |  | 
| TIMESTAMP | bigint(20) | YES |  | NULL |  | 
+-----------+--------------+------+-----+---------+-------+ 

在這個表中，我們審覈像 '簽到'， 'SIGNUP'， '關閉' 用戶操作。在這種情況下，我們希望從此表中更快地獲得詳細信息。但是這將有數百萬條目。

值在我的表中。

select * from Users; 
+------+----------+-----------------------+--------+---------------+ 
| ID | USER  | EMAIL_ID    | MODE | TIMESTAMP  | 
+------+----------+-----------------------+--------+---------------+ 
| 1 | kannan | kannanrbk.r@gmail.com | SIGNIN | 1353864896000 | 
| 2 | bharathi | bharathikannan.r  | SIGNUP | 1353864934000 | 
| 2 | mack  | mack@gmail.com  | SIGNIN | 1353865121000 | 
| 2 | david | david@gmail.com  | SIGNIN | 1353865130000 | 
+------+----------+-----------------------+--------+---------------+ 

查詢：

select EMAIL_ID from Users where TIMESTAMP > 1353864896000; 

explain輸出：

+----+-------------+-------+------+---------------+------+---------+------+------+-------------+ 
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra  | 
+----+-------------+-------+------+---------------+------+---------+------+------+-------------+ 
| 1 | SIMPLE  | Users | ALL | NULL   | NULL | NULL | NULL | 4 | Using where | 
+----+-------------+-------+------+---------------+------+---------+------+------+-------------+ 

看解釋輸出

它檢查表中的整行。因爲這個查詢不是作爲range之一執行的。我們要爲TIMESTAMP列創建索引。

在爲時間戳列創建的索引之後解釋輸出。

+----+-------------+-------+------+---------------+------+---------+------+------+-------------+ 
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra  | 
+----+-------------+-------+------+---------------+------+---------+------+------+-------------+ 
| 1 | SIMPLE  | Users | ALL | t_dx   | NULL | NULL | NULL | 4 | Using where | 
+----+-------------+-------+------+---------------+------+---------+------+------+-------------+ 

它仍然不作爲範圍查詢執行。因爲我們只索引TIMESTAMP列。我們希望創建一個組合索引TIMESTAMP,EMAIL_ID以執行此查詢作爲範圍一。

create index t_dx on Users(TIMESTAMP,EMAIL_ID); 

在創建組合索引後解釋輸出。

+----+-------------+-------+-------+---------------+------+---------+------+------+--------------------------+ 
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra     | 
+----+-------------+-------+-------+---------------+------+---------+------+------+--------------------------+ 
| 1 | SIMPLE  | Users | range | t_dx   | t_dx | 9  | NULL | 3 | Using where; Using index | 
+----+-------------+-------+-------+---------------+------+---------+------+------+--------------------------+ 

現在，它執行範圍查詢並查看所檢查的行數，它只在給定時間條件之上進行掃描。組合索引將有助於大型表格。

Answer 3

它不一定是一個任何一種情況。假設你有訂單表：

orderid integer, 
orderdate date, 
etc... 

和的OrderDetail表

orderid integer, 
lineno integer, 
productID integer, 
etc... 

，因爲你要做上查找所有的時間你可能會在orderdetail.orderid想索引和DBMS將用它來驗證你的外鍵查詢的參照完整性，返回到orders。然而，你可能會風做了很多選擇，看起來像的：

select * 
from orderdetail 
where orderid=? 
order by lineno 

在這種情況下，orderdetail.orderid,orderdetail.lineno指數將是有益的。