爲什麼不使用MySQL索引合併？

Question

使用表stucture爲http://sqlfiddle.com/#!2/572f9/2，

1. 爲什麼不使用使用的索引僅僅COMPANY_ID和創建的索引？

2. 爲什麼在我的機器上，使用完全相同的表結構和查詢，在POSSIBLE_KEYS列中只出現company_id？ MySQL版本：5.5.24-0ubuntu0.12.04.1日誌（Ubuntu的）

Answer 1

我很確定你運行在5.5中存在的錯誤並且使用5.6修復。在使用不同於utf8_general_ci的排序規則時，此處不會使用日期時間列的索引。請參閱以下鏈接：http://bugs.mysql.com/bug.php?id=68942和http://bugs.mysql.com/bug.php?id=64998。

對於在最左邊部分具有日期時間值的組合索引，情況也是如此。所以一個可能的解決方案是創建一個不以datetime開頭的組合索引。請使用上面的示例參閱下面的示例測試會話。

因此，在你的情況下，我會嘗試像Vatev建議的那樣去使用組合索引，但請記住不要使用datetime列來啓動它。如果使用此索引，則將取決於優化程序。但它將被列爲可能的關鍵。一個不同的解決方案是使用5.1.xx或5.6（只有機會對5.6.12進行驗證，但是bug報告聲明它不會在5.1.60中發生）。

mysql> SHOW VARIABLES LIKE "version"; 
+---------------+------------+ 
| Variable_name | Value  | 
+---------------+------------+ 
| version  | 5.5.28-log | 
+---------------+------------+ 
1 row in set (0.00 sec) 

mysql> show variables like '%collation%'; 
+----------------------+-------------------+ 
| Variable_name  | Value    | 
+----------------------+-------------------+ 
| collation_connection | utf8_general_ci | 
| collation_database | latin1_swedish_ci | 
| collation_server  | latin1_swedish_ci | 
+----------------------+-------------------+ 
3 rows in set (0.00 sec) 

mysql> CREATE TABLE tbl (
    -> id int(11) not null auto_increment PRIMARY KEY, 
    -> user_id int(11) not null, 
    -> company_id int (11) NOT NULL, 
    -> created TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, 
    -> oid int(11) NOT NULL, 
    -> did varchar(100) NOT NULL, 
    -> status int(11) NOT NULL, 
    -> KEY company_id (company_id), 
    -> KEY user_id (user_id), 
    -> KEY created (created), 
    -> KEY operator_id (oid), 
    -> KEY did (did) 
    ->); 
Query OK, 0 rows affected (0.01 sec) 

mysql> EXPLAIN SELECT DATE_FORMAT(created, '%M %d, %Y') as date, count(id) as num_accepted FROM tbl WHERE created BETWEEN '2013-06-29' AND '2013-07-30' AND company_id = 20 AND (status in (2,5)) GROUP BY `date` ORDER BY created ASC; 
+----+-------------+-------+------+--------------------+------------+---------+-------+------+----------------------------------------------+ 
| id | select_type | table | type | possible_keys  | key  | key_len | ref | rows | Extra          | 
+----+-------------+-------+------+--------------------+------------+---------+-------+------+----------------------------------------------+ 
| 1 | SIMPLE  | tbl | ref | company_id,created | company_id | 4  | const | 1 | Using where; Using temporary; Using filesort | 
+----+-------------+-------+------+--------------------+------------+---------+-------+------+----------------------------------------------+ 
1 row in set (0.00 sec) 

mysql> SET collation_connection = utf8_unicode_ci; 
Query OK, 0 rows affected (0.00 sec) 

mysql> EXPLAIN SELECT DATE_FORMAT(created, '%M %d, %Y') as date, count(id) as num_accepted FROM tbl WHERE created BETWEEN '2013-06-29' AND '2013-07-30' AND company_id = 20 AND (status in (2,5)) GROUP BY `date` ORDER BY created ASC; 
+----+-------------+-------+------+---------------+------------+---------+-------+------+----------------------------------------------+ 
| id | select_type | table | type | possible_keys | key  | key_len | ref | rows | Extra          | 
+----+-------------+-------+------+---------------+------------+---------+-------+------+----------------------------------------------+ 
| 1 | SIMPLE  | tbl | ref | company_id | company_id | 4  | const | 1 | Using where; Using temporary; Using filesort | 
+----+-------------+-------+------+---------------+------------+---------+-------+------+----------------------------------------------+ 
1 row in set (0.00 sec) 

Answer 2

的MySQL在運行時決定取決於它使對錶的統計信息使用哪個索引。根據數據選擇不同的查詢計劃是正常的。

對於這個查詢，它將不得不使用相交索引合併，這是不是非常有效，它決定（正確與否）不這樣做。

如果您在(company_id,status,created)上創建索引，會更好。這樣它就能夠直接從索引過濾結果。

我想不出爲什麼只有其中一個鍵出現的原因（假設你確實有兩個鍵）。