2011-05-14 345 views
0

我有連接查詢,似乎緩慢提取。我如何優化它,或者它合理嗎?MySQL查詢優化

的時間來執行
29總計,查詢花費1.6956秒

MySQL查詢

SELECT SQL_CALC_FOUND_ROWS 
    t2.AuctionID ,t2.product_name ,t3.user_name ,t1.date_time ,t1.owned_price 
    ,t2.specific_product_id 
FROM table_user_ownned_auction AS t1 
INNER JOIN table_product AS t2 ON t1.specific_product_id=t2.specific_product_id 
INNER JOIN table_user_information AS t3 ON t3.user_id=t1.user_id 
ORDER BY ownned_id DESC 

這裏的解釋輸出

Explain output

+1

你能告訴我們索引了哪些列嗎?桌子有多大? – stevevls 2011-05-14 11:23:06

+2

您是否需要'SQL_CALC_FOUND_ROWS',因爲沒有指定'LIMIT'? – Alec 2011-05-14 11:26:08

+0

@alec:我認爲沒有理由爲它是不帶'LIMIT' – Nanne 2011-05-14 11:27:42

回答

0

望着解釋輸出,你的問題是在 Explain output

第二行:與表t1的加入。
將指數放在t1.specific_product_idt2.specific_product_id之間。

第一行有一行3行,using filesort這實際上比使用索引快,因爲它節省了I/O時間。

以下代碼將添加一個索引到t2.specific_product_id

ALTER TABLE table_product ADD INDEX spi(specific_product_id); 

因爲你只有29行的輸出,使用索引應加快查詢到瞬間。

+0

如何將索引添加到specific_product_id字段。它的已經是primary_key。我不知道任何關於index.untill know.help我! – Gowri 2011-05-14 12:32:59

+0

@gowri,更新了答案以包含添加索引的語句。 – Johan 2011-05-15 16:57:49

0

如果喲ü要了解查詢的性能問題,只需使用EXPLAIN關鍵字查詢的面前:

EXPLAIN SELECT SQL_CALC_FOUND_ROWS 
    ,t2.AuctionID ,t2.product_name ,t3.user_name ,t1.date_time ,t1.owned_price 
    ,t2.specific_product_id 
FROM table_user_ownned_auction AS t1 inner 
JOIN table_product AS t2 ON t1.specific_product_id=t2.specific_product_id 
INNER JOIN table_user_information AS t3 ON t3.user_id=t1.user_id 
ORDER BY ownned_id DESC 

它會告訴你有關查詢重要信息。最重要的欄目是「關鍵」和「額外」。

如果「key」爲NULL,則需要索引。主要用於WHEREGROUP BYORDER BY語句中使用的列。 「額外」告訴你關於資源消耗(CPU或內存)的操作。

因此,在「ownned_id」(我認爲應該是「owned_id」)上添加一個索引並再次解釋。然後看性能增益。

如果您遇到問題,我可以幫助您更好地粘貼EXPLAIN輸出。

+0

任何問題,您能解釋一下..這裏是解釋輸出http://awesomescreenshot.com/0ceczlte5 – Gowri 2011-05-14 11:48:00

+0

我如何能指標ownned_id列其已經primary_key和經銷商的增量 – Gowri 2011-05-14 11:55:31

+0

主要手段,它索引,也是絕無僅有的。所以不需要爲它添加另一個索引。關於你的EXPLAIN輸出的解釋請看Johan的答案。 – Alp 2011-05-14 12:33:30

0

通過看你的解釋表,類型都這是非常糟糕的,如果你有超過10 000行中的表。我在你的餐桌強烈建議索引此列

  1. t1.specific_product_id
  2. t2.specific_product_id
  3. t3.user_id
  4. t1.user_id

如果您應該表達到10 000排,你應該能夠看到性能提升。有關更多信息,請在00:00到02:04分鐘之間播放此視頻,因爲您可以在下面的視頻中查詢索引之前必須搜索超過90000行數據,並在索引之後搜索少於5行的數據我會幫你的。

https://www.youtube.com/edit?o=U&video_id=ojyEcNMAj8k