2009-10-22 185 views
0

查詢:如何優化此查詢?

select id, 
     title 
    from posts 
where id in (23,24,60,19,21,32,43,49,9,11,17,34,37,39,46,5 
2,55) 

解釋計劃:

mysql> explain select id,title from posts where id in (23,24,60,19,21,32,43,49,9,11,17,34,37,39,46,5 
2,55); 
+----+-------------+-------+------+---------------+------+---------+------+------+-------------+ 
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra  | 
+----+-------------+-------+------+---------------+------+---------+------+------+-------------+ 
| 1 | SIMPLE  | posts | ALL | PRIMARY  | NULL | NULL | NULL | 30 | Using where | 
+----+-------------+-------+------+---------------+------+---------+------+------+-------------+ 
1 row in set (0.05 sec) 

ID是職位表的主鍵。

+0

我不認爲你可以:你正在選擇主鍵的顯式值,而且你的EXPLAIN預期會有不同的結果(即30行而不是18),這可能是由於optimizer交互的方式與統計。或者我誤解了你的問題? – davek 2009-10-22 14:37:05

+0

@Dave K 30這裏是MySQL爲了處理查詢而希望讀取的行數,它不是它在結果列表中所期望的行數。由於它只需要很少的行(可能全部包含在單個節點中,或幾個任意速率),因此「掃描」比「查找」更有效。 – mjv 2009-10-22 14:51:50

+0

如果你正在尋找一個單一的ID,這個計劃是什麼樣子? – Thorsten 2009-10-22 19:55:31

回答

3

除了添加其他索引,例如

  • 聚簇索引ID
  • 覆蓋索引,其中包括ID [第一]並從SELECT子句

似乎有其它列要做的事情很少......

事實上,即使有這樣的索引可用,MySQL可能會決定做一個表掃描,這裏就是這種情況(「ALL」類型)。原因可能是該表可能只有相對較少的行(與查詢將返回的估計行數相比),因此「讀取」表順序更有效,順序丟棄不匹配的行,而不是「希望到處都有」,而且索引是間接的。

0

我沒有看到任何問題。如果您需要根據列表進行選擇,那麼「IN」是正確的做法。你沒有選擇不必要的信息,你選擇的東西是一個關鍵,這可能是索引。