MySQL緩慢查詢與行發送/檢查等於0

我有一個Rails（v.2.3.8）應用程序與MySQL數據庫。在數據庫服務器上的慢查詢日誌中，有大量條目，如：MySQL緩慢查詢與行發送/檢查等於0

# Query_time: 3.471884 Lock_time: 0.000000 Rows_sent: 0 Rows_examined: 0 
use prod; 
SET timestamp=1312909843; 
SELECT * FROM `pages` WHERE (`pages`.`controller` = 'forum_categories' AND `pages`.`action` = 'show') LIMIT 1;

注意查詢時間3.47秒，而發送和檢查的行數都是0。當我使用MySQL客戶端（在MySQL服務器和應用服務器上）運行相同的查詢，我得到的結果不到100ms。所有必要的表字段都被編入索引，表中只有70條記錄。任何想法爲什麼這些長期運行，看似無用的查詢將運行？

謝謝。

來源

2011-08-09 modulaaron

您是否在第pages.controller和pages.action列上有索引鍵？

該表可能有很多條目，因此如果您沒有實現索引鍵，查詢需要3.47秒才能逐一查找正確的行。

來源

2011-08-12 09:16:14

下面是從慢查詢日誌的例子：
1 # Time: 030303 0:51:27 
2 # [email protected]: root[root] @ localhost [] 
3 # Query_time: 25 Lock_time: 0 Rows_sent: 3949 Rows_examined: 378036 
4 SELECT ... 
1個線顯示當記錄查詢，第2只顯示出了誰執行它。 3行顯示有多少秒花了執行，它多久在MySQL服務器級別（而不是在存儲引擎級別）等待表鎖，...

要小心，不要過分解讀進入慢速查詢日誌。如果您在日誌中多次查看相同的查詢，則很有可能它的速度較慢，需要優化。但僅僅因爲查詢出現在日誌中並不意味着它是一個錯誤的查詢，或者甚至是一個緩慢的查詢。 您可能會發現緩慢的查詢，自己運行它，並發現它在幾分之一秒內執行。出現在日誌中意味着查詢需要很長時間;這並不意味着現在或將來需要很長時間。有很多原因可以使查詢在其他時間有時很快並且速度較慢：
•表可能已被鎖定，會導致查詢等待。 Lock_time表示查詢等待鎖釋放的時間。
•數據或索引可能不是已被緩存在內存中。當MySQL第一次啓動或者沒有很好調整時，這是很常見的。
•夜間備份過程可能有正在運行，使所有磁盤I/O速度變慢。
•服務器可能已經同時運行其他查詢，從而減慢此查詢的速度。
作爲的結果，您應該將慢速查詢日誌視爲發生的部分記錄。您可以使用它來生成一個可能的嫌疑犯列表，但您需要更深入地調查每個嫌疑犯。通過巴倫·施瓦茨等人優化，備份，複製，以及更多，第二版，：

來源

2011-08-12 09:35:36 Dor

其他查詢是否快速運行？這可能是系統資源問題。 – jschorr

MySQL緩慢查詢與行發送/檢查等於0

回答

相關問題