Linux command: sort

Almost everybody learns sort in their first week of Linux and then never learns it again. It puts lines in order, and that looks like the whole story. It is not. sort decides the order using rules that come from your environment rather than from your command line, so the same command on the same file can give two different answers on two machines. It sorts numbers wrongly unless you tell it they are numbers. Its -u can quietly throw away a line you wanted to keep, and its -k2 almost never means what people think it means. It is also one of the very few commands in daily use that can run a server out of memory. This article is about what sort really compares, and how to make it compare the thing you meant.

2. Where the Name Comes From

There is no puzzle here, and that is itself worth noticing. Its neighbours from the same era were cut to the bone: ls, cp, mv, rm, du, df, wc. sort kept all four of its letters because there was no obvious way to shorten it and still be understood. srt would have saved a keystroke and cost a great deal of clarity.

The vocabulary is where the real confusion lives, because sort uses several ordinary words in a very specific way. Every one of these terms causes a misunderstanding somewhere in this article:

line             what sort moves around; the trailing newline is not compared
key              the part of a line sort actually compares (default: all of it)
field            a numbered piece of a line, counting from 1
separator        what divides fields; by default a run of blanks, -t changes it
collation        the rules that decide which string comes first
locale           where those rules come from: LC_COLLATE, or LC_ALL, or LANG
stable           lines that compare equal keep their input order  (-s)
last resort      when every key ties, sort compares the whole line anyway
merge            combining already-sorted inputs without sorting again  (-m)
external sort    sorting more data than fits in memory, using temporary files

Two of those deserve a warning right now. A key is not the same as a field: -k2 names a key that starts at field 2 and runs to the end of the line, which is section 5.2 and the most common mistake with this command. And last resort means sort quietly compares things you never asked it to compare, which is section 6.1 and the reason its output is deterministic when you expected a tie.

The manual page is honest about the locale trap from section 1.3, and it shouts, which the GNU manuals almost never do:

$ man sort | grep -A3 WARNING
       ***  WARNING  ***  The locale specified by the environment affects sort
       order.  Set LC_ALL=C to get the traditional sort order that uses native
       byte values.

4. Simple Use Cases

4.1 Alphabetical, and Backwards

-r (short for reverse) does not sort backwards. It reverses the result of every individual comparison, which amounts to the same thing for a plain sort but matters once you have several keys (section 5.4):

$ sort -r fruit.txt
Banana
banana
Apple
apple

Multiple files are treated as one long file, concatenated and then sorted. This is different from sorting each one:

$ sort file1.txt file2.txt file3.txt      # one merged, sorted stream

4.2 Numbers: -n, -g and -h

There are three numeric sorts and they are not interchangeable. Picking the wrong one gives a plausible-looking wrong answer, which is the worst kind.

The difference between -n and -g is visible in one example:

$ printf '1e3\n5\n0.5\n2\n-1\ninf\nnan\n' > gen.txt

$ sort -n gen.txt
-1
inf                       # -n cannot read these, so both count as 0
nan
0.5
1e3                       # and this counts as 1, not 1000
2
5

$ sort -g gen.txt
nan
-1
0.5
2
5
1e3                       # 1000, correctly at the top
inf

The reverse trap is just as real. -n honours the thousands separator of your locale and -g does not:

$ printf '1,200\n999\n1,100\n' | sort -n       # en_US.UTF-8
999
1,100
1,200

$ printf '1,200\n999\n1,100\n' | sort -g
1,100                     # both read as "1", then compared as text
1,200
999

-h exists because -n makes a mess of human-readable sizes. It reads the suffix instead of stopping at it:

$ printf '1.4G\n900M\n2K\n1023\n1.1T\n' > sizes.txt

$ sort -h sizes.txt
1023
2K
900M
1.4G
1.1T

$ sort -n sizes.txt
1.1T                      # 1.1, 1.4, 2, 900, 1023: the suffix is ignored
1.4G
2K
900M
1023

The pairing rule is worth memorising, because mixing the two is a common pipeline bug: -h goes with output that has suffixes, -n goes with output that does not. du -h | sort -h is right and du -k | sort -n is right; du -h | sort -n is the wrong answer, dressed up correctly.

4.3 Versions: -V

-V (short for Version) sorts the way a human reads a release number, which is neither text order nor numeric order:

$ printf 'v1.10\nv1.9\nv1.2\nv1.21\n' > vers.txt

$ sort vers.txt
v1.10
v1.2
v1.21
v1.9

$ sort -V vers.txt
v1.2
v1.9
v1.10
v1.21

It is not only for version numbers. It is the right tool for anything where digits are embedded in text: log.2 before log.10, eth1 before eth10, photo-9.jpg before photo-10.jpg. It also happens to sort IPv4 addresses correctly, which surprises people:

$ printf '10.0.0.9\n10.0.0.100\n10.0.2.1\n9.1.1.1\n10.0.0.10\n' | sort -V
9.1.1.1
10.0.0.9
10.0.0.10
10.0.0.100
10.0.2.1

4.4 Removing Duplicates: -u

-u (short for unique) keeps only the first line of each run of equal lines. It replaces the older sort | uniq and saves a process:

$ printf 'a\nb\na\nb\na\n' | sort -u
a
b

Two things about it will bite you later, and both have their own sections. -u decides "equal" using whatever comparison is currently in force, not by comparing bytes, so sort -uf and sort -un throw away much more than you expect (section 7.3). And sort -u destroys the information that uniq -c would have given you, which is why the frequency counter in section 5.6 uses uniq rather than -u.

4.5 Sorting Is Not the Same as Counting

The relatives of sort all need sorted input, and that is the whole reason sort turns up at the front of so many pipelines. uniq only ever compares a line with the one directly before it:

$ printf 'a\nb\na\nb\na\n' | uniq
a
b
a
b
a                         # nothing removed: no two neighbours were equal

$ printf 'a\nb\na\nb\na\n' | sort | uniq
a
b

The same applies to comm and join, which is section 7.1.

4.6 Writing the Result: -o, and the Trap Next to It

The obvious way to sort a file in place is the one that destroys it:

$ cat danger.txt
c
a
b

$ sort danger.txt > danger.txt
$ wc -c < danger.txt
0                         # the file is gone

This is not sort's fault. The shell creates and truncates danger.txt before sort ever starts, so sort opens an empty file, reads nothing, and writes nothing. Every command in the shell behaves this way; sort just happens to be the one people try it with.

-o (short for output) is the fix, and it has known about this case since Version 4 Unix. sort reads the input fully before it opens the output, so naming the same file is explicitly safe:

$ printf 'c\na\nb\n' > safe.txt
$ sort -o safe.txt safe.txt
$ cat safe.txt
a
b
c

It is safe even when the output file is one of several inputs:

$ printf 'c\na\n' > o1.txt ; printf 'd\nb\n' > o2.txt
$ sort -o o1.txt o1.txt o2.txt
$ cat o1.txt
a
b
c
d

6. Advanced Use Cases

6.1 Ties, Stability and the Last-Resort Comparison

What does sort do when two lines compare equal on every key you gave it? Most people assume it leaves them alone. It does not. GNU sort falls back on comparing the entire line, as if you had given no options at all except -r. The manual calls this the last-resort comparison.

$ cat stab.txt
2 zebra
1 apple
2 apple
1 zebra

$ sort -k1,1n stab.txt
1 apple
1 zebra
2 apple
2 zebra                   # the second column got sorted too, uninvited

Field 2 was never mentioned on that command line. sort compared it anyway, because both lines tied on field 1. -s (short for stable) turns the fallback off, and equal lines then keep their original order:

$ sort -s -k1,1n stab.txt
1 apple
1 zebra
2 zebra
2 apple                   # input order preserved within each group

This matters more than it looks. The last-resort comparison is what makes GNU sort deterministic: run it twice on the same input and you get the same output, regardless of how the merge happened to interleave things. Turn it off with -s and the order within a group becomes the input order, which is what you want when you are sorting data that already carries a meaningful sequence, such as a log you have sorted by severity but want to keep in time order within each severity.

The awkward part is that -u also switches the fallback off, silently. That combination is section 7.3, and it can lose data.

6.2 Checking Instead of Sorting: -c and -C

-c (short for check) does not sort. It reports whether the input is already in order and tells you the first line that is not:

$ printf 'a\nc\nb\n' > unsorted.txt
$ sort -c unsorted.txt
sort: unsorted.txt:3: disorder: b
$ echo $?
1

$ printf 'a\nb\nc\n' | sort -c
$ echo $?
0

-C is the same check with no message, for scripts that only want the exit code. The three exit codes are worth knowing because they are not the usual two:

$ sort /nonexistent
sort: cannot read: /nonexistent: No such file or directory
$ echo $?
2

Adding -u to a check turns it into a check for strict ordering, which means duplicates now count as disorder. That is a one-line duplicate detector:

$ printf 'a\na\nb\n' | sort -c
$ echo $?
0                         # sorted: duplicates are allowed

$ printf 'a\na\nb\n' | sort -cu
sort: -:2: disorder: a
$ echo $?
1                         # not strictly sorted: there is a duplicate

In a script, sort -C is much cheaper than sorting a large file you suspect is already sorted, because it never buffers anything: it streams, compares each line with the previous one, and stops at the first problem.

6.3 Merging Already-Sorted Files: -m

-m (short for merge) combines files that are already sorted, without sorting them again. It streams, so it needs almost no memory whatever the file sizes:

$ printf '1\n3\n5\n' > m1.txt ; printf '2\n4\n6\n' > m2.txt
$ sort -m m1.txt m2.txt
1
2
3
4
5
6

It trusts you completely. Give it unsorted input and it produces unsorted output with no warning at all:

$ printf '5\n1\n' > m3.txt
$ sort -m m1.txt m3.txt
1
3
5
5
1                         # garbage, silently

There is a second requirement that is easier to miss, because every input can be perfectly sorted and the merge still produces nonsense. The inputs must be sorted by the same rules. Merge a file sorted in the C locale with one sorted in a UTF-8 locale and the result is not in either order:

$ printf 'a-b\nab\nAb\n' | LC_ALL=C sort > p1.txt      # byte order
$ printf 'a-c\nac\nAc\n' | sort > p2.txt              # locale order

$ LC_ALL=C sort -m p1.txt p2.txt
Ab
a-b
a-c
ab
ac
Ac

$ LC_ALL=C sort -m p1.txt p2.txt | LC_ALL=C sort -c
sort: -:6: disorder: Ac                # the merge output is not sorted at all

The same applies to the key. sort -m -k2,2 over files that were sorted on field 1 will interleave them by field 2 and produce garbage, without a word of complaint. A merge is only as good as the promise you make about its inputs, and sort takes that promise entirely on trust.

So -m is the right tool for rotated logs, daily exports and anything else that arrives in pre-sorted chunks, as long as every chunk was produced by the same command in the same environment. It is the wrong tool for anything you have not verified, so pair it with -C and set the locale explicitly on both sides:

$ export LC_ALL=C
$ for f in chunk-*.txt; do sort -C "$f" || { echo "$f is not sorted"; exit 1; }; done
$ sort -m chunk-*.txt > merged.txt

6.4 Character Positions Inside a Field

The .C part of a key selects characters within a field, which lets you sort on a substring without cutting the line apart first. Given fixed-width timestamps:

$ cat logs.txt
2026-03-01 12:00:00 ERROR disk
2026-01-15 08:30:00 WARN  net
2026-01-15 22:00:00 INFO  boot
2025-12-31 23:59:59 ERROR eol

$ sort -k2.1,2.2 logs.txt         # by the hour only
2026-01-15 08:30:00 WARN  net
2026-03-01 12:00:00 ERROR disk
2025-12-31 23:59:59 ERROR eol
2026-01-15 22:00:00 INFO  boot

$ sort -k1.6,1.7 logs.txt         # by the month inside the date
2026-01-15 08:30:00 WARN  net
2026-01-15 22:00:00 INFO  boot
2026-03-01 12:00:00 ERROR disk
2025-12-31 23:59:59 ERROR eol

Reading -k1.6,1.7 out loud helps: "field 1, characters 6 to 7". That is the month in an ISO date.

This only works on genuinely fixed-width data. If the field can shift by a character, use awk to build a proper column first. Which brings up the general principle: sorting by an ISO 8601 date needs no options at all, because YYYY-MM-DD was designed so that text order and date order are the same thing. If you control the format, that is the format to choose.

6.5 Months, Blanks, Case and Punctuation

Four smaller ordering options exist, and three of them are more useful than they look.

-M (short for Month) understands month abbreviations, with anything unrecognised sorting first:

$ printf 'Mar\nJan\nFeb\nDec\nfoo\nJul\n' | sort -M
foo
Jan
Feb
Mar
Jul
Dec

It is case-insensitive, and it accepts full month names as well as three-letter ones. The names it accepts come from your locale, which makes it useless on a server whose locale you do not control and a trap on one whose locale is not English.

-b (short for ignore leading blanks) removes leading whitespace from the key before comparing. In byte order a space sorts before every letter, so indented lines float to the top without it:

$ printf '  zulu\nbravo\n' > blank.txt

$ LC_ALL=C sort blank.txt
  zulu                    # the two spaces win
bravo

$ LC_ALL=C sort -b blank.txt
bravo
  zulu

-f (short for case fold) makes the comparison case-insensitive. In a UTF-8 locale this is close to the default behaviour anyway; in the C locale it changes everything:

$ printf 'Zebra\napple\nBanana\n' > f.txt

$ LC_ALL=C sort f.txt
Banana
Zebra
apple                     # all capitals first

$ LC_ALL=C sort -f f.txt
apple
Banana
Zebra

-d (short for dictionary order) considers only letters, digits and blanks, ignoring punctuation. -i (short for ignore non-printing) drops control characters such as tabs and escape sequences from the comparison, which is occasionally useful on coloured command output that has been captured to a file.

LC_ALL=C sort -df is a reasonable approximation of "sort this the way a phone book would", and unlike a UTF-8 locale it will still behave the same way after a glibc upgrade.

6.6 Filenames: -z and --files0-from

Filenames may contain newlines. That is legal on Linux, and it means any pipeline built out of lines can be broken by a filename, deliberately or by accident. -z (short for zero-terminated) switches both input and output to NUL bytes, which cannot appear in a filename:

$ find /var/www -type f -print0 | sort -z | xargs -0 ls -l

Every tool in that chain uses the NUL convention: find -print0, sort -z, xargs -0. Mixing them with a line-based tool defeats the point. grep -z, sed -z and du --files0-from=- are the other members of the family.

sort also has --files0-from=F, which reads its list of input files from a NUL-separated list rather than from the command line. That avoids the "argument list too long" limit when you have a very large number of files:

$ find /var/log -name '*.csv' -print0 > list0
$ sort --files0-from=list0 -t, -k2,2n > combined.csv

6.7 Shuffling: -R

-R (short for Random) is described in the manual as "shuffle, but group identical keys", and that second half is the part that matters. It hashes the key and sorts on the hash, so identical lines still end up next to each other:

$ printf 'a\na\nb\nb\nc\nc\n' | sort -R --random-source=seed
b
b
c
c
a
a                         # groups intact, group order random

$ printf 'a\na\nb\nb\nc\nc\n' | shuf --random-source=seed
b
c
b
a
c
a                         # genuinely shuffled

The exact permutation depends on the seed file, so your own run will look different. What does not change is the shape: sort -R keeps the pairs together and shuf does not.

If you want a real shuffle, use shuf. If you want to randomise the order of groups while keeping each group together, sort -R is the only thing that does it. Both accept --random-source, which makes the result reproducible: the same seed file gives the same permutation every time, which is what you want in a test.

6.8 When It Does Not Fit: the External Merge Sort

Section 1.2 said sort has to hold the whole input before it can output anything. That raises an obvious question: what happens when the whole input does not fit in memory? A lot of people assume it fails, or thrashes. It does neither. It switches strategy, and the strategy is worth understanding because it explains every tuning option in the next section.

The technique is called an external merge sort, and it works in two phases:

PHASE 1  make runs                PHASE 2  merge runs
read as much as the buffer holds  open 16 runs at once
sort it in memory                 read the smallest line from each
write it out as a sorted "run"    write it to the output
repeat until the input is gone    repeat until every run is empty
                                  more than 16 runs left? merge again

Each run is sorted, so merging them needs only one line from each in memory at a time, however large the runs are. That is the whole trick: sorting needs everything at once, merging does not.

You can watch it happen. Give sort a small buffer, point -T at a directory you can see, and count the files in it while the sort runs:

$ sort -S 10M -T ./tmpdir big.txt -o /dev/null &
$ while kill -0 $! 2>/dev/null; do ls tmpdir | wc -l; done | uniq

0 1 2 3 4 5 6 7 8 ... 66 67 68 69      <- phase 1: one run at a time
69 63 57 54 53 46 39 35 29 24 23       <- phase 2: runs consumed and merged
16 10 8 3 2 1 0

The climb to 69 is phase 1: the 62 MB input divided by a 10 MB buffer. The decline is phase 2. It is not a neat staircase, because each merge deletes its sixteen inputs one at a time as it drains them while its own output file is already there, so the count wobbles down rather than dropping in blocks.

Sixteen is not a guess: --batch-size defaults to 16, and the coreutils manual says so. With 69 runs that means sort cannot do it in one pass. It merges groups of 16 into new temporary files, then merges those, so the data is read and rewritten twice on its way out. The next few paragraphs put a number on what that costs.

The size of the buffer decides how many runs there are, and that is the only thing -S really controls:

Read the last three rows carefully, because they contain the most useful practical fact in this section. -S 50M was as fast as the default and used one thirteenth of the memory. Once the number of runs drops below the batch size, one merge pass is enough, and buying more memory after that buys nothing. Note also that -S 2G did not use 2 GB: -S is a ceiling, not a reservation.

The reason is easiest to see if you stop counting seconds and start counting bytes moved. For an external sort that is the unit that matters, because every merge pass reads and rewrites the entire data set. Measured on the same 62 MB file, as total bytes read plus written by the process:

in memory, no runs        61 MB read  +  61 MB written  =   123 MB   ( 2x )
-S 50M,  14 runs, 1 pass 123 MB read  + 123 MB written  =   247 MB   ( 4x )
-S 10M,  69 runs, 2 pass 182 MB read  + 182 MB written  =   365 MB   ( 6x )

Each merge pass costs one more full read and one more full write. That is the whole cost model, and it turns --batch-size from a mystery into arithmetic. Forcing more passes on the same 136 runs:

$ sort -S 5M --batch-size=2   ...   1091 MB moved
$ sort -S 5M --batch-size=4   ...    611 MB moved
$ sort -S 5M --batch-size=16  ...    365 MB moved    (the default)
$ sort -S 5M --batch-size=200 ...    247 MB moved    (all 136 runs at once)

For a sort that fits in memory, think in seconds. For a sort that does not, think in bytes moved. Every extra merge pass rewrites your entire data set, and the buffer size is only interesting because it decides how many passes there are.

This also explains the No space left on device failure that catches nightly jobs. The runs all exist at once before the merging starts, so a sort needs temporary space of roughly the size of its input, in /tmp, on top of the space its output will take somewhere else.

6.9 Tuning a Big Sort

Five options control the machinery from the previous section. Only the first two are worth touching often.

All the numbers here come from the same 5,000,000-line, 62 MB file on one machine. Pushed to an extreme, a tiny buffer produces a lot of runs and a slow sort:

$ sort -S 1M -T ./tmpdir big.txt -o /dev/null       1.66 s, 717 temporary files
$ sort            big.txt -o /dev/null              0.82 s, no temporary files

Two things follow for -T. First, if /tmp is small, a big sort fails with No space left on device even though the disk holding your data has plenty of room, because the temporary files land somewhere else entirely. Peak temporary usage in the run above was about 87 MB for a 62 MB input. Second, -T pointing at a tmpfs is not always a win: tmpfs lives in RAM, so you have moved the memory problem rather than solved it.

For -S, the practical advice is the opposite of what people expect. Do not reach for a big number. Reach for a number that gets the run count under the batch size and stop there: on this file -S 50M matched the default's speed at one thirteenth of its memory. A cap also protects the rest of the machine, because the default will take whatever it needs.

Compression is the option people reach for first and need least:

$ sort -S 1M -T ./tmpdir big.txt -o /dev/null                        1.61 s
$ sort -S 1M -T ./tmpdir --compress-program=gzip big.txt -o /dev/null 7.37 s

On an NVMe SSD, compressing temporary files made the sort four and a half times slower. It pays off only when the temporary filesystem is genuinely too small or genuinely slow, such as a network mount. Measure before you add it.

8. Best Practices

• Put export LC_ALL=C at the top of any script that sorts. It makes the order identical on every machine, under cron, inside a container and after an OS upgrade, and it is roughly twice as fast. Leave the locale alone only for output a person will read.
• Always write the end of the key. -k2,2, not -k2. The comma is the difference between "field 2" and "field 2 to the end of the line", and the wrong one is usually right by accident until it is not.
• Put the ordering letter on the key. -k3,3n, not -n -k3,3. A global -n applies to every key, and turns your text key into zero.
• Reach for --debug the moment something looks wrong. It underlines the exact bytes being compared and names the locale. It answers in one second what guessing answers in ten minutes.
• Learn the frequency counter by heart: sort | uniq -c | sort -rn | head. It answers most log questions.
• Use -o file, never > file, when the output goes back to the input. The shell truncates the file before sort opens it.
• Match the numeric sort to the data. -h for suffixed sizes, -n for plain numbers, -V for version and release numbers, -g only for scientific notation.
• Use ISO dates and you will not need a date sort. YYYY-MM-DD HH:MM:SS sorts correctly as plain text, in every locale, with no options.
• Be careful with -u when you have also given a key or an ordering option. It keeps one arbitrary line per group. If you mean "remove exact duplicates", use plain LC_ALL=C sort -u.
• Verify before you merge. sort -m trusts its input completely and produces silent garbage if that input is not sorted. sort -C is a cheap guard.
• Cap the memory of big sorts, and cap it low: -S 50M -T /var/tmp. The default takes whatever it needs (691 MB for a 62 MB file here) and a small buffer matched it exactly, because all that matters is getting the run count under the batch size. The temporary files go to /tmp, which is often the smallest filesystem you have.
• For a sort that spills to disk, count bytes moved, not seconds. Every merge pass reads and rewrites the whole data set. That is why -S helps and why lowering --batch-size hurts (section 6.8).
• Never merge chunks that were sorted by different rules. -m assumes one order across every input. Set LC_ALL=C and the same key on the side that writes the chunks and on the side that merges them.
• Filter before you sort, not after. grep, cut and awk stream and cost nothing; sort buffers everything.
• Use -z with find -print0 and xargs -0 whenever filenames come from somewhere you do not control.
• Be considerate on shared servers. A large sort takes eight cores by default. --parallel=2 and nice keep the rest of the machine responsive.
• Do not add --compress-program without measuring. On fast local storage it makes sorting several times slower.
• Read the manual once. It is short, and the shouted warning at the bottom of it is the most important sentence about this command.

$ man 1 sort
$ sort --help              # the KEYDEF paragraph at the bottom is the useful part
$ info coreutils 'sort invocation'
$ man 1 uniq               # sort's constant companion
$ man 1 comm ; man 1 join  # both need matching sort orders
$ man 1 shuf ; man 1 tsort

10. Summary

sort looks like the simplest command in the toolbox and is one of the subtlest. Everything awkward about it comes from three facts, and once you hold those three in your head the rest stops being surprising.

It borrows its order from the environment. There is no built-in alphabetical order; there is LC_COLLATE, which differs between your shell, your cron job, your container and your colleague's laptop, and which changed for everyone in 2018.

It compares a key, not a line. The default key happens to be the whole line, which hides the distinction until you write your first -k and it goes wrong.

It has to read everything before it can print anything. That single constraint produces the memory use, the temporary files, the missing streaming behaviour, and the reason it is worth filtering before you sort.

• export LC_ALL=C in every script that sorts. Identical output everywhere, immune to OS upgrades, and about twice as fast.
• Write -k2,2, not -k2. Without the end field the key runs to the end of the line, which is almost never what you meant.
• Put the ordering letter on the key, as in -k3,3n. A global -n flattens your text keys to zero.
• --debug ends every argument about this command. It underlines the bytes being compared, names the locale, and says no match for key when your key is empty.
• Pick the right numeric sort: -h for 1.4G, -n for plain numbers, -V for log.2 before log.10, -g only for 1e3.
• sort | uniq -c | sort -rn | head answers most log questions. The first sort is there so uniq can work at all.
• sort file > file empties the file. Use sort -o file file, which has been safe since Version 4 Unix.
• -u keeps one arbitrary line per equal group, not the smallest one, and with -f, -n or a key "equal" is much broader than "identical".
• Ties are not left alone: sort compares the whole line as a last resort. -s turns that off and keeps input order.
• -m merges without checking. Guard it with -C, which returns 1 for "not sorted" and 2 for a real error.
• Big sorts cost about eleven times the file size in RAM and spill into /tmp. -S 50M -T /var/tmp is the fix, and it is not a compromise: a small buffer matched the default's speed at one thirteenth of the memory. Filtering first is better still.
• When it spills, it becomes an external merge sort: sorted runs on disk, merged 16 at a time. Count bytes moved, not seconds, because every extra merge pass rewrites the whole data set (123 MB in memory, 247 MB with one pass, 365 MB with two).
• It has been multi-threaded since 2010 and stops gaining after 8 threads: 1.87 s at --parallel=1, 0.79 s at 8, and 0.79 s at 16.
• -R is not shuf, sort -t, is not a CSV parser, and tsort is a completely different command that resolves dependencies.

This is the quick reference worth keeping:

THE ONES TO REMEMBER
sort | uniq -c | sort -rn | head    what appears most often
LC_ALL=C sort                       same order everywhere, and faster
sort -o file file                   sort in place  ( > file EMPTIES it )
sort --debug ...                    show me the key you are actually using

ORDERING
-n    plain numbers          -h    1023 < 2K < 900M < 1.4G
-g    also 1e3, inf, nan     -V    log.2 before log.10, and IPv4
-r    reverse EVERY key      -M    Jan Feb Mar (locale month names)
-f    ignore case            -b    ignore leading blanks
-d    letters/digits only    -i    ignore control characters

KEYS   -k F[.C][OPTS][,F[.C][OPTS]]
-k2      field 2 TO END OF LINE      <- almost never what you want
-k2,2    field 2 only                <- write this
-k3,3n   field 3, numeric            <- letter ON the key, not global
-k1,1 -k3,3nr   name up, number down
-k1.6,1.7       field 1, characters 6-7
-t:      one literal separator; repeats make EMPTY fields
default  a RUN of blanks is one separator

MODES
-u    keep one line per equal group  (arbitrary; disables last resort)
-s    stable: equal lines keep input order
-c    is it sorted?   -C  same, quietly.  exit 1 = no, 2 = error
-cu   is it sorted AND free of duplicates?
-m    merge pre-sorted files; checks NOTHING, and assumes every
      input used the SAME locale and the SAME key

BIG FILES   ( when it does not fit: sorted runs on disk, merged 16 at a time )
-S 50M         cap the buffer LOW; matched the default at 1/13th the RAM
-T /var/tmp    spill here, not /tmp   ( needs ~1x the input, plus the output )
--parallel=2   be polite on a shared box   ( default caps at 8 )
--compress-program=gzip   only if temp SPACE is the problem; costs speed
--batch-size   leave it alone. lowering it multiplies the bytes moved
every merge pass re-reads AND re-writes everything: 2x, 4x, 6x the file

SAFE FILENAMES
find . -print0 | sort -z | xargs -0 ...

TEAMMATES
uniq -c/-d/-u   comm -12/-23/-13   join   shuf   tsort

LC_ALL=C for programs.  The locale for people.  --debug when in doubt.

Most of the time sort is a five-second command that does exactly what you expect. The trouble starts when its output feeds something else: a comparison against yesterday's list, a comm against a backup, a deduplicated export, a nightly job that has run fine for two years and then fails after an upgrade. Those are the moments when the order matters more than the sorting, and they are usually cheaper to prevent than to debug.