sql查詢限制行數之間的性能差異

是什麼這個查詢之間的區別

Showing rows 0 - 299 (1,422 total, Query took 1.9008 sec) 
    SELECT 1 FROM `p_apartmentbuy` p 
    where 
    p.price between 500000000 and 900000000 
    and p.yard = 1 
    and p.dateadd between 1290000000 and 1320000000 
    ORDER BY `p`.`id` desc 
    limit 1669

解釋 enter image description here

這一個：

Showing rows 0 - 299 (1,422 total, Query took 0.2625 sec) 
    SELECT 1 FROM `p_apartmentbuy` p 
    where 
    p.price between 500000000 and 900000000 
    and p.yard = 1 
    and p.dateadd between 1290000000 and 1320000000 
    ORDER BY `p`.`id` desc 
    limit 1670

解釋： enter image description here

這兩查詢正在使用同一數據的一個表，並具有相同的地方clasue，但只有限制行數不同

來源

2012-04-09 Hamidreza

MySQL有一個排序緩衝區。當要排序的東西太大時，它會對大塊進行排序，然後將它們合併排序。這被稱爲「filesort」。您的第1670行顯然只是溢出排序緩衝區。

查看更多詳細信息here。

現在爲什麼它選擇另一個關鍵的內存排序...我不太確定;但顯然它的策略不太好，因爲它最終變慢了。

來源

2012-04-09 16:00:17 Amadan

有同樣的頁面緩存在MySQL？這在SQL Server中很常見，因爲數據在內存中，第二次運行速度更快。 – JNK 2012-04-09 16:01:37

tnx for answer。我如何禁用這個緩衝區進行排序？ – Hamidreza 2012-04-09 16:05:32

你可以設置'@@ sort_buffer_size'，但這是一個破解。有一件事要嘗試的是「選擇...使用指數（碼）」，以確保使用更快的策略;看看'EXPLAIN'說了些什麼。 – Amadan 2012-04-09 16:14:53

回顧：奇怪的是，該查詢返回更多的行運行得更快

這個緩衝VS文件排序，排序1400只記錄不涉及不到1秒鐘

需要以及第一說明顯示查詢優化器做線性掃描，第二個解釋使用索引顯示它。即使是部分有用的指數通常也比無。

在內部，mysql維護有關索引大小的統計信息，並試圖猜測哪個索引或線性掃描是否會更快。這個估計數據是特定數據的，我已經看到mysql在100箇中使用了99次正確的索引，但是每隔一段時間選擇一個不同的索引並且將查詢運行得慢50倍。

您可以覆蓋內置的查詢優化器，並指定索引手動使用，用SELECT ... FROM ... FORCE INDEX（...）

來源

2015-02-10 04:17:10 Andras

sql查詢限制行數之間的性能差異

回答

相關問題