mysql選擇的時間與實際行不一樣

Question

我在我的mysql服務器中遇到了一個意外的結果。

行數越多，查詢時間越少？

我有一個表，併爲每個過濾器總行：

select count(*) from tcr where eid=648; 
+----------+ 
| count(*) | 
+----------+ 
| 11336 | 
select count(*) from tcr where eid=997; 
+----------+ 
| count(*) | 
+----------+ 
| 1262307 | 

但查詢時間oppisite總線每個過濾器：

select * from tcr where eid=648 order by start_time desc limit 0,10; 
[data display] 
10 rows in set (16.92 sec) 

select * from tcr where eid=997 order by start_time desc limit 0,10; 
[data display] 
10 rows in set (0.21 sec) 

「重置查詢緩存」已經在每個查詢sql之前執行。 表TCR的指數是

KEY `cridx_eid` (`eid`), 
KEY `cridx_start_time` (`start_time`) 

BTW：附上解釋的結果：這是很奇怪，但它看起來更像是我們採取的reuslt（的EID = 997具有比EID = 648

線少

explain select * from talk_call_record where eid=648 order by start_time desc limit 0,10; 
+----+-------------+------------------+-------+---------------+------------------+---------+------+------+-------------+ 

| ID | SELECT_TYPE |表|類型| possible_keys |關鍵| key_len |裁判|行|額外| + ---- + ------------- + --- --------------- + ------- + -------- + ---------- -------- + --------- + ------ + ------ + ------------- + | 1 | SIMPLE | talk_call_record | index | cridx_eid | cridx_start_time | 5 | NULL | 3672 | Usi ng where |

explain select * from talk_call_record where eid=997 order by start_time desc limit 0,10; 
+----+-------------+------------------+-------+---------------+------------------+---------+------+------+-------------+ 

| id | select_type | table   | type | possible_keys | key    | key_len | ref | rows | Extra  | 
+----+-------------+------------------+-------+---------------+------------------+---------+------+------+-------------+ 
| 1 | SIMPLE  | talk_call_record | index | cridx_eid  | cridx_start_time | 5  | NULL | 32 | Using where | 

Answer 1

首先，你必須有一個非常大的表。

MySQL正在使用start_time上的索引進行查詢。現在發生的事情是，它一次一行地走過桌子。它發現eid=997比發現eid=648快得多。它只需要找到10條記錄，所以引擎在到達第10條時就停下來。

你能做什麼？查詢的最佳索引是(eid, start_time)上的複合索引。這將直接轉到您想要的值。