正如許多人所指出的，Quicksort的平均案例性能比mergesort更快。 但這只有在假設您有恒定的時間按需訪問任何內存時才是正確的。

在RAM中，此假設通常不太差（由于高速緩存，它并不總是正確的，但也不太糟）。但是，如果您的數據結構足夠大，可以存儲在磁盤上，那么快速排序就會因您的平均磁盤每秒執行200次隨機尋道而被殺死。但是，同一張磁盤沒有順序順序讀取或寫入每秒兆字節數據的麻煩。mergesort正是這樣做的。

因此，如果必須在磁盤上對數據進行排序，那么您真的很想在mergesort上使用一些變體。（通常，您先對子列表進行快速排序，然后在某個大小閾值以上開始將它們合并在一起。）

此外，如果您必須對如此大小的數據集執行任何操作，請認真考慮如何避免尋找磁盤。例如，這就是為什么這樣的建議，即在數據庫中進行大量數據加載之前先刪除索引，然后再重建索引，這是標準建議。在加載期間保持索引意味著不斷尋找磁盤。相反，如果刪除索引，則數據庫可以通過以下方式重建索引：首先對要處理的信息進行排序（當然使用mergesort！），然后將其加載到該索引的BTREE數據結構中。（BTREE本質上是保持順序的，因此您可以從排序的數據集中加載一個，而很少有磁盤尋道。）

在很多情況下，了解如何避免磁盤尋道使我使數據處理作業花費數小時而不是數天或數周。

實際上，QuickSort是O（n ²）。它的平均運行時間為O（nlog（n）），但最差的運行時間為O（n ²），當您在包含很少的唯一項目的列表上運行它時，會發生這種情況。隨機化為O（n）。當然，這不會改變最壞的情況，它只是防止惡意用戶使您的排序花費很長時間。

QuickSort之所以受歡迎，是因為它：

1. 就地（MergeSort要求額外的內存與要排序的元素數量成線性關系）。

2. 有一個小的隱藏常數。