为什么合并排序更适合大数组，而快速排序适合小数组？

如何解决为什么合并排序更适合大数组，而快速排序适合小数组？

我认为使用合并排序而不是快速排序的唯一原因是列表是否已经（或大部分）排序。

归并排序需要更多空间，因为它会创建一个额外的数组用于存储，并且不管它会比较每个项目。

另一方面，快速排序不需要额外的空间，并且不会进行不必要的交换或比较。

因为数据集大或小而说一个比另一个更好似乎是不直观的。

例如，引用 Geeksforgeeks 的文章：

归并排序适用于任何类型的数据集，无论其大小（大或小）。 然而 快速排序不适用于大型数据集。

接下来它说：

合并排序没有到位，因为它需要额外的内存空间来存储辅助数组。 然而 快速排序已经到位，因为它不需要任何额外的存储空间。

我知道空间复杂度和时间复杂度是分开的。但这仍然是一个额外的步骤，当然，将所有内容写入具有大数据集的新数组需要更多时间。

至于旋转问题，数据集越大，选择最低或最高项目的机会就越低（除非它再次是一个几乎排序的列表）。

那么为什么认为归并排序比快速排序更适合对大数据集进行排序？

解决方法

为什么合并排序更适合大数组，而快速排序适合小数组？ 说由于数据集大或小，一个比另一个更好，这似乎是不直观的。

假设数据集适合内存（未调出），问题不在于数据集的大小，而是特定快速排序实现的最坏情况模式，导致 O(n²) 时间复杂度。快速排序可以使用中位数来保证最坏情况下的时间复杂度为 O(n log(n))，但这最终使其比合并排序慢得多。如果递归级别太深，另一种方法是切换到堆排序，称为介绍排序，并在某些库中使用。

https://en.wikipedia.org/wiki/Median_of_medians

https://en.wikipedia.org/wiki/Introsort

归并排序需要更多空间，因为它会创建一个额外的数组用于存储，并且不管它会比较每个项目。

有些合并排序的变体不需要任何额外的数据存储空间，但它们往往比标准合并排序慢 50% 以上。

另一方面，快速排序不需要额外的空间，并且不会进行不必要的交换或比较。

子数组的每个元素都将与枢轴元素进行比较。随着相等元素数量的增加，Lomuto 分区方案变得更糟，而 Hoare 分区方案变得更好。由于有很多相等的元素，Hoare 分区方案会不必要地交换相等的元素，但避免交换的检查通常比仅仅交换花费更多的时间。

对指向对象的指针数组进行排序

合并排序比快速排序移动更多，但比较更少。如果对指向对象的指针数组进行排序，则仅移动指针，但比较对象需要尊重指针以及比较对象所需的内容。在这种情况下以及比较花费比移动更多时间的其他情况下，归并排序更快。

不适合内存的大型数据集

对于太大而无法放入内存的数据集，内存基础排序用于对数据集的“块”进行排序，这些“块”将适合内存，然后写入外部存储。然后使用 k-way 合并将外部存储上的“块”合并以生成排序数据集。

https://en.wikipedia.org/wiki/External_sorting

,

除了 rcgldr 的详细回复，我想强调一些额外的考虑：

• large 和 small 是相当相关的：在许多库中，小数组（少于 30 到 60 个元素）通常使用插入排序进行排序。如果数组已经排序，这个算法更简单并且是最优的，尽管在最坏的情况下具有二次复杂性。

• 除了空间和时间复杂性之外，稳定性是一个可能需要的特性，在某些情况下甚至是必要的。 合并排序和插入排序都是稳定的（比较相等的元素保持相同的相对顺序），而使用快速排序很难实现稳定性.

• 正如您提到的，快速排序的最坏情况时间复杂度为 O(N²)，并且库没有实现中位数来抑制这种不利因素。许多只使用 3 的中位数或 9 的中位数，有些在两个分支上天真地递归，在最坏的情况下为堆栈溢出铺平了道路。这是一个主要问题，因为可以精心制作数据集以表现出最坏情况下的行为，从而导致拒绝服务攻击、减慢甚至使服务器崩溃。 Doug McIlroy 在他 1999 年著名的论文 A Killer Adversary for Quicksort 中发现了这个问题。实现是 available，并且已经使用这种技术进行了攻击（参见 this discussion）。

• 几乎排序的数组在实践中很常见，快速排序和合并排序都没有真正有效地处理它们。库现在使用更高级的技术组合（例如 Timsort）来实现更好的性能和稳定性。