MySQL内核月报 2015.01-TokuDB·特性分析· Optimize Table-阿里云开发者社区

开发者社区> 阿里云数据库> 正文

MySQL内核月报 2015.01-TokuDB·特性分析· Optimize Table

简介:

来自一个TokuDB用户的“投诉”:

https://mariadb.atlassian.net/browse/MDEV-6207

现象大概是:

用户有一个MyISAM的表test_table:


转成TokuDB引擎后表大小为92M左右:


执行"OPTIMIZE TABLE test_table":


再次执行"OPTIMIZE TABLE test_table":


继续执行:


基本稳定在这个大小。

主索引从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

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
阿里云数据库
使用钉钉扫一扫加入圈子
+ 订阅

帮用户承担一切数据库风险,给您何止是安心!

官方博客
链接