MySQL核心月報 2015.01-TokuDB·特性分析· Optimize Table

來自一個tokudb使用者的“投訴”:

<a href="https://mariadb.atlassian.net/browse/mdev-6207">https://mariadb.atlassian.net/browse/mdev-6207</a>

現象大概是:

使用者有一個myisam的表test_table:

轉成tokudb引擎後表大小為92m左右:

執行"optimize table test_table":

再次執行"optimize table test_table":

繼續執行:

基本穩定在這個大小。

主索引從47m--&gt;63m--&gt;79m，執行"optimize table"後為什麼會越來越大？

這得從tokudb的索引檔案配置設定方式說起，當記憶體中的髒頁需要寫到磁盤時，tokudb優先在檔案末尾配置設定空間并寫入，而不是“覆寫”原塊，原來的塊暫時成了“碎片”。

這樣問題就來了，索引檔案豈不是越來越大？no, tokudb會把這些“碎片”在checkpoint時加入到回收清單，以供後面的寫操作使用，看似79m的檔案其實還可以裝不少資料呢！

嗯，這個現象解釋通了，但還有2個問題:

1) 在執行這個語句的時候，tokudb到底在做什麼呢？

<dl><dd>在做toku_ft_flush_some_child，把内節點的緩沖區(message buffer)資料刷到最底層的葉節點。</dd></dl>

2) 在tokudb裡，optimize table有用嗎？

<dl><dd>作用非常小，不建議使用，tokudb是一個"no fragmentation"的引擎。</dd></dl>