MySQL · TokuDB · TokuDB數據文件大小計算 · 數據庫內核月報

想要查看TokuDB某個表占了多少磁盤空間，目前還沒有太好的方法。如果你使用’show table status’命令，得到的結果只會讓你更迷茫: ~~~ Name: toku Engine: TokuDB Version: 10 Row_format: tokudb_zlib Rows: 28874059 Avg_row_length: 30 Data_length: 868159449 Max_data_length: 9223372036854775807 Index_length: 2099497463 Data_free: 0 ~~~ 我們來看看test_toku表磁盤文件大小： ~~~ $du -b _test_toku* 124427776 _test_toku_A_B.tokudb --KEY(A,B)索引數據文件 215959552 _test_toku_B_C.tokudb --KEY(B,C)索引數據文件 149504000 _test_toku_main.tokudb --主數據文件 ~~~ Data_length和Index_length都對不上，而且差的還不是一點，真頭疼，總不能每次都要去服務器上du吧？其實，我們可以通過`information_schema.TokuDB_fractal_tree_info`得到： ~~~ mysql> select * from TokuDB_fractal_tree_info where table_name='test_toku'\G; *************************** 1\. row *************************** dictionary_name: ./test/test_toku_A_B internal_file_name: _test_toku_A_B.tokudb bt_num_blocks_allocated: 449 bt_num_blocks_in_use: 449 bt_size_allocated: 124416093 bt_size_in_use: 123563101 table_schema: test table_name: toku table_dictionary_name: key-test_toku_A_B *************************** 2\. row *************************** dictionary_name: ./test/test_toku_B_C internal_file_name: ./_test_toku_B_C.tokudb bt_num_blocks_allocated: 612 bt_num_blocks_in_use: 612 bt_size_allocated: 215945353 bt_size_in_use: 214784137 table_schema: test table_name: toku table_dictionary_name: key-test_toku_B_C *************************** 3\. row *************************** dictionary_name: ./test/test_toku-main internal_file_name: ./_test_toku_main.tokudb bt_num_blocks_allocated: 486 bt_num_blocks_in_use: 486 bt_size_allocated: 149491745 bt_size_in_use: 148580897 table_schema: test table_name: toku table_dictionary_name: main ~~~ `bt_size_allocated`字段是TokuDB內部維護當前數據文件最后分配的offset，跟數據文件磁盤大小基本一致。再回到剛才的問題：`show table status`里Data_length和Index_length為什么跟實際大小出入這么大呢？在`ha_tokudb::info()`里: ~~~ stats.data_file_length = dict_stats.bt_dsize; ~~~ bt_dsize的值來自toku_ft_stat64: ~~~ bt_dsize = ft->in_memory_stats.numbytes; ~~~ `in_memory_stats.numbytes`是TokuDB在內存中維護的一個變量，用于記錄變更數據的增量大小，每次checkpoint的時候持久化到數據文件(包括索引文件)的header里，所以是個出入比較大的參考變量(無壓縮)，已不能通過此變量來反應表文件的真實大小。這么不爽的地方，我們(RDS MySQL)已準備好patch把它修掉，讓`show table status`可以拿到TokuDB表文件的真實大小。