Why Redirecting Large MySQL Dumps Is Up to 3× Faster Than Using Pipes

Two common ways to import a large MySQL dump are compared: using a pipe (cat huge_dump.sql | mysql -uroot) and using input redirection (mysql -uroot < huge_dump.sql). The question is which method is more efficient.

# Command 1: pipe import
shell> cat huge_dump.sql | mysql -uroot

# Command 2: redirection import
shell> mysql -uroot < huge_dump.sql

A small C program b.out is compiled to simulate MySQL's data consumption:

int main(int argc, char *argv[]) {
    while (fread(buf, sizeof(buf), 1, stdin) > 0);
    return 0;
}
$ gcc -o b.out b.c
$ ./b.out < huge_dump.sql

A SystemTap script is used to trace system calls during both import methods.

$ cat test.stp
function should_log(){
  return (execname() == "cat" || execname() == "b.out" || execname() == "bash");
}
probe syscall.open, syscall.close, syscall.read, syscall.write, syscall.pipe, syscall.fork, syscall.execve, syscall.dup, syscall.wait4 {
  if (!should_log()) next;
  printf("%s -> %s
", thread_indent(0), probefunc());
}
probe kernel.function("pipe_read"), kernel.function("pipe_readv"), kernel.function("pipe_write"), kernel.function("pipe_writev") {
  if (!should_log()) next;
  printf("%s -> %s: file ino %d
", thread_indent(0), probefunc(), __file_ino($filp));
}
probe begin { println(":~") }

A 419 MB file huge_dump.sql is generated (cached in page cache, not on disk) and the two import methods are timed:

# Pipe method
time (cat huge_dump.sql | ./b.out)
real    0m0.596s
user    0m0.001s
sys     0m0.919s

# Redirection method
time (./b.out < huge_dump.sql)
real    0m0.151s
user    0m0.000s
sys     0m0.147s

The redirection method is about three times faster. SystemTap logs reveal why:

In the pipe case, bash forks two processes , then execs cat and b.out, which communicate via a pipe. Data is read from the file, written to the pipe, and read again by b.out, causing two reads and one write plus a context switch.

In the redirection case, bash forks only one process , opens the file, dup‑s the file descriptor to stdin, and execs b.out. The program reads the data directly, resulting in a single read operation.

Therefore, the extra read/write cycle and additional process in the pipe method explain the ~3× slowdown.

Conclusion: On Linux, redirecting a large file directly into a program is significantly more efficient than piping the file through an intermediate cat process.