'sort -u'对于大型文件的可伸缩性

'sort -u'的合理可伸缩性限制是多少？（以“行长”，“行数”，“文件总大小”为单位？）

对于超出“行数”维的文件，Unix的替代方案是什么？（当然，我可以轻松实现一个，但是我想知道是否可以用很少的标准Linux命令来完成某些工作？）

将sort你在Linux上找到来自的coreutils包和工具的外部R-路合并。它将数据拆分成可以在内存中处理的数据块，将其存储在磁盘上，然后合并它们。如果机器具有处理器，则这些块将并行完成。

因此，如果有限制，则可用磁盘空间sort来存储必须合并的临时文件以及结果。

我不能说供应商特定的实现，但是该UNIX sort实现将大文件拆分为较小的文件，对这些文件进行排序，然后将排序的较小文件组合为汇总的排序输出。

唯一的限制是中间创建的较小文件的磁盘空间sort，但是可以通过设置环境变量将文件重定向到任意目录TMPDIR。

基于https://blog.mafr.de/2010/05/23/sorting-large-files/和/unix//a/88704/9689：

split -n l/20 input input-
for inpf in input-* ; do
    sort --parallel="$(nproc --all)" "${inpf}" > sorted-"{$inpf}"
done
sort -m sorted-input-* > sorted-input

更新：

从上面的答案中，我们sort已经可以看到所提到的代码段即外部R-Way合并。所以毕竟运行只是：

sort --parallel="$(nproc --all)" -u input > output

应该足够了。

我目前关于限制的假设（没有检查代码）是：

• 最大行长受物理内存量限制。排序需要至少两个适合内存
• 行数-我不知道
• 文件大小-当然按文件系统
• 并行打开的文件数量-取决于操作系统（感谢Diomidis Spinellis指出这一点！）

（此答案被标记为社区Wiki-受到鼓励进行改进！:)）