[[315910]]

# 命令1，管道導入 
shell> cat huge_dump.sql | mysql -uroot; 

# 命令2，重定向導入 
shell> mysql -uroot < huge_dump.sql; 

大家先看一下上面二個命令，假如huge_dump.sql文件很大，然后猜測一下哪種導入方式效率會更高一些?

這個問題挺有意思的，我的第一反應是：沒比較過，應該是一樣的，一個是cat負責打開文件，一個是bash

這種場景在MySQL運維操作里面應該比較多，所以就花了點時間做了個比較和原理上的分析：

我們先構造場景：

首先準備一個程序b.out來模擬mysql對數據的消耗：

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

再來寫個systemtap腳本用來方便觀察程序的行為。

$ 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\n", 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\n",  thread_indent(0), probefunc(), __file_ino($filp)); 
} 
probe begin { println(":~") } 

這個腳本重點觀察幾個系統調用的順序和pipe的讀寫情況，然后再準備個419M的大文件huge_dump.sql,在我們幾十G內存的機器很容易在內存里放下：

$ sudo dd if=/dev/urandom of=huge_dump.sql bs=4096 count=102400 
102400+0 records in 
102400+0 records out 
419430400 bytes (419 MB) copied, 63.9886 seconds, 6.6 MB/s 

因為這個文件是用bufferio寫的，所以它的內容都cache在pagecahce內存里面，不會涉及到磁盤。

好了，場景齊全了，我們接著來比較下二種情況下的速度，第一種管道：

# 第一種管道方式 
$ time (cat huge_dump.sql|./b.out) 
  
real    0m0.596s 
user    0m0.001s 
sys     0m0.919s 
  
# 第二種重定向方式 
$ time (./b.out <huge_dump.sql) 
  
real    0m0.151s 
user    0m0.000s 
sys     0m0.147s 

從執行時間數看出來速度有3倍左右的差別了，第二種明顯快很多。

是不是有點奇怪?好吧我們來從原來上面分析下，還是繼續用數據說話：

這次準備個很小的數據文件，方便觀察然后在一個窗口運行stap

$ echo hello > huge_dump.sql 
$ sudo stap test.stp 
:~ 
     0 bash(26570): -> sys_read 
     0 bash(26570): -> sys_read 
     0 bash(26570): -> sys_write 
     0 bash(26570): -> sys_read 
     0 bash(26570): -> sys_write 
     0 bash(26570): -> sys_close 
     0 bash(26570): -> sys_pipe 
     0 bash(26570): -> sys_pipe 
     0 bash(26570): -> do_fork 
     0 bash(26570): -> sys_close 
     0 bash(26570): -> sys_close 
     0 bash(26570): -> do_fork 
     0 bash(13775): -> sys_close 
     0 bash(13775): -> sys_read 
     0 bash(13775): -> pipe_read: file ino 20906911 
     0 bash(13775): -> pipe_readv: file ino 20906911 
     0 bash(13776): -> sys_close 
     0 bash(13776): -> sys_close 
     0 bash(13776): -> sys_close 
     0 bash(13776): -> do_execve 
     0 bash(26570): -> sys_close 
     0 bash(26570): -> sys_close 
     0 bash(26570): -> sys_close 
     0 bash(13775): -> sys_close 
     0 bash(26570): -> sys_wait4 
     0 bash(13775): -> sys_close 
     0 bash(13775): -> sys_close 
     0 b.out(13776): -> sys_close 
     0 b.out(13776): -> sys_close 
     0 bash(13775): -> do_execve 
     0 b.out(13776): -> sys_open 
     0 b.out(13776): -> sys_close 
     0 b.out(13776): -> sys_open 
     0 b.out(13776): -> sys_read 
     0 b.out(13776): -> sys_close 
     0 cat(13775): -> sys_close 
     0 cat(13775): -> sys_close 
     0 b.out(13776): -> sys_read 
     0 b.out(13776): -> pipe_read: file ino 20906910 
     0 b.out(13776): -> pipe_readv: file ino 20906910 
     0 cat(13775): -> sys_open 
     0 cat(13775): -> sys_close 
     0 cat(13775): -> sys_open 
     0 cat(13775): -> sys_read 
     0 cat(13775): -> sys_close 
     0 cat(13775): -> sys_open 
     0 cat(13775): -> sys_close 
     0 cat(13775): -> sys_open 
     0 cat(13775): -> sys_read 
     0 cat(13775): -> sys_write 
     0 cat(13775): -> pipe_write: file ino 20906910 
     0 cat(13775): -> pipe_writev: file ino 20906910 
     0 cat(13775): -> sys_read 
     0 b.out(13776): -> sys_read 
     0 b.out(13776): -> pipe_read: file ino 20906910 
     0 b.out(13776): -> pipe_readv: file ino 20906910 
     0 cat(13775): -> sys_close 
     0 cat(13775): -> sys_close 
     0 bash(26570): -> sys_wait4 
     0 bash(26570): -> sys_close 
     0 bash(26570): -> sys_wait4 
     0 bash(26570): -> sys_write 

stap在收集數據了，我們在另外一個窗口運行管道的情況：

$ cat huge_dump.sql|./b.out 

我們從systemtap的日志可以看出：

• bash fork了2個進程。
• 然后execve分別運行cat 和 b.out進程, 這二個進程用pipe通信。
• 數據從由cat從 huge_dump.sql讀出，寫到pipe,然后b.out從pipe讀出處理。

那么再看下命令2重定向的情況：

$ ./b.out < huge_dump.sql 
  
stap輸出： 
      0 bash(26570): -> sys_read 
     0 bash(26570): -> sys_read 
     0 bash(26570): -> sys_write 
     0 bash(26570): -> sys_read 
     0 bash(26570): -> sys_write 
     0 bash(26570): -> sys_close 
     0 bash(26570): -> sys_pipe 
     0 bash(26570): -> do_fork 
     0 bash(28926): -> sys_close 
     0 bash(28926): -> sys_read 
     0 bash(28926): -> pipe_read: file ino 20920902 
     0 bash(28926): -> pipe_readv: file ino 20920902 
     0 bash(26570): -> sys_close 
     0 bash(26570): -> sys_close 
     0 bash(26570): -> sys_wait4 
     0 bash(28926): -> sys_close 
     0 bash(28926): -> sys_open 
     0 bash(28926): -> sys_close 
     0 bash(28926): -> do_execve 
     0 b.out(28926): -> sys_close 
     0 b.out(28926): -> sys_close 
     0 b.out(28926): -> sys_open 
     0 b.out(28926): -> sys_close 
     0 b.out(28926): -> sys_open 
     0 b.out(28926): -> sys_read 
     0 b.out(28926): -> sys_close 
     0 b.out(28926): -> sys_read 
     0 b.out(28926): -> sys_read 
     0 bash(26570): -> sys_wait4 
     0 bash(26570): -> sys_write 
     0 bash(26570): -> sys_read 

• bash fork了一個進程，打開數據文件。
• 然后把文件句柄搞到0句柄上，這個進程execve運行b.out。
• 然后b.out直接讀取數據。

現在就非常清楚為什么二種場景速度有3倍的差別：

• 命令1，管道方式： 讀二次，寫一次,外加一個進程上下文切換。
• 命令2，重定向方式：只讀一次。

結論：Linux下大文件重定向效率更高。