爲標題態運行速度非常快，在我的數據庫各種查詢出現在慢查詢日誌，但是當我手動運行他們，他們運行速度快10倍。MYSQL慢查詢「慢查詢日誌」 - 但相同的查詢手動
例如，一個相對簡單的選擇查詢與幾個順序PARAMS在日誌中經常需要100秒（是表是非常大）...但是當我自己在同一個DB上運行它需要2秒左右。
我已經檢查了服務器的性能和似乎沒有要在一個特定的時間放緩或瓶頸，也有很多疑問需要長時間在這一時期，但只是一個。
我該如何開始分析這樣的問題？
感謝您的幫助
當違規查詢進入慢日誌時，您的系統可能更忙。
慢日誌可以指示索引沒有被充分如果rows_examined比結果組更大利用。因此，執行時間應該被視爲查詢有問題的線索，但rows_examined會給你更多的明確答案。
對於高負載的服務器，查詢時間是一個糟糕的性能測量，因爲任何查詢在繁忙的服務器上可能會很慢。您應該使用EXPLAIN和SHOW PROFILE來分析您的查詢並改進它們，以便它們不會給您的服務器帶來太多負載。
使用SELECT SQL_NO_CACHE ...進行查詢性能分析時，結果不會存儲在查詢緩存中，否則後續執行的同一查詢可能會使用查詢緩存，從而導致查詢的任何時間發生偏差。
關於緩存：當我手動運行查詢（仍然在服務器上，而不是本地，在同一個數據庫上）時，我改變了某些條件的順序，所以它將無法將結果與先前運行的查詢進行匹配。 我跑瞭解釋，它確實顯示它使用了一些索引，但我真的不確定它們是否正確。在「可能的索引」列表中還有許多其他沒有使用的索引。 –
我也注意到，掃描的行數大大超過了實際獲取的行數。事實上語句本身具有LIMIT 50就可以了，掃描行是3000左右 我的想法是，它給訂單的到期時間在聲明中，這在我的理解去抓取所有行（即使有限制對查詢）只有在它的訂單返回50.這是正確的？ –
@MikiBergin，如果ORDER BY子句可以由索引提供，那麼它不一定要獲取所有行。有一些警告，但這裏討論太多了。我建議如果您在優化特定查詢時需要幫助，請發佈一個單獨的問題，其中包含整個查詢，相關架構以及EXPLAIN和SHOW PROFILE結果。 –
我想通過在沿有一個分析在這裏發佈此類查詢的一個援助開始「EXPLAIN SELECT ...」，顯示引擎希望其查詢執行路徑做什麼。 – DRapp
通常情況下，如果查詢需要1秒或更長時間纔會被慢查詢日誌捕獲。 2秒肯定高於1秒。 –
瘋狂猜測：手動運行時查詢速度很快，因爲結果在第一次執行查詢期間被緩存。要檢查出來，清除所有緩存，然後再次嘗試相同的查詢 - 應該需要100秒。 – nikhil500