來自一個TokuDB用戶的“投訴”: [https://mariadb.atlassian.net/browse/MDEV-6207](https://mariadb.atlassian.net/browse/MDEV-6207) 現象大概是: 用戶有一個MyISAM的表test_table: ~~~ CREATE TABLE IF NOT EXISTS `test_table` ( `id` int(10) unsigned NOT NULL, `pub_key` varchar(80) NOT NULL, PRIMARY KEY (`id`), KEY `pub_key` (`pub_key`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1; ~~~ 轉成TokuDB引擎后表大小為92M左右: ~~~ 47M _tester_testdb_sql_61e7_1812_main_ad88a6b_1_19_B_0.tokudb 45M _tester_testdb_sql_61e7_1812_key_pub_key_ad88a6b_1_19_B_1.tokudb ~~~ 執行"OPTIMIZE TABLE test_table": ~~~ 63M _tester_testdb_sql_61e7_1812_main_ad88a6b_1_19_B_0.tokudb 61M _tester_testdb_sql_61e7_1812_key_pub_key_ad88a6b_1_19_B_1.tokudb ~~~ 再次執行"OPTIMIZE TABLE test_table": ~~~ 79M _tester_testdb_sql_61e7_1812_main_ad88a6b_1_19_B_0.tokudb 61M _tester_testdb_sql_61e7_1812_key_pub_key_ad88a6b_1_19_B_1.tokudb ~~~ 繼續執行: ~~~ 79M _tester_testdb_sql_61e7_1812_main_ad88a6b_1_19_B_0.tokudb 61M _tester_testdb_sql_61e7_1812_key_pub_key_ad88a6b_1_19_B_1.tokudb ~~~ 基本穩定在這個大小。 主索引從47M-->63M-->79M，執行"OPTIMIZE TABLE"后為什么會越來越大？ 這得從TokuDB的索引文件分配方式說起，當內存中的臟頁需要寫到磁盤時，TokuDB優先在文件末尾分配空間并寫入，而不是“覆寫”原塊，原來的塊暫時成了“碎片”。 這樣問題就來了，索引文件豈不是越來越大？No, TokuDB會把這些“碎片”在checkpoint時加入到回收列表，以供后面的寫操作使用，看似79M的文件其實還可以裝不少數據呢！ 嗯，這個現象解釋通了，但還有2個問題: 1) 在執行這個語句的時候，TokuDB到底在做什么呢？ 在做toku_ft_flush_some_child，把內節點的緩沖區(message buffer)數據刷到最底層的葉節點。 2) 在TokuDB里，OPTIMIZE TABLE有用嗎？ 作用非常小，不建議使用，TokuDB是一個"No Fragmentation"的引擎。 官方WIKI:?[Optimize Table](https://github.com/Tokutek/tokudb-engine/wiki/Optimize-Table)