随着业务的发展以及mysql存储数据量的越来越大，很多超大表不仅仅存储变的不易，维护也变得越来越困难，特别是频繁的ddl操作让运维变得痛苦不堪。当然表拆分可以解决类似的问题，但是对一个稳定的系统来说，表拆分对业务的影响（表”路由“或统计等）有时可能无法接受，因此迫切需要一款合适的存储引擎来解决类似的问题，技术圈里近来一直在讨论2013开源的一款TokuDB存储引擎，于是正好拿来进行了一系列的对比测试，看是否可以作为一个解决的备用方案。
硬件及参数配置说明
TokuDB传说中牛叉的特性
1，在线创建索引，快速的索引插入和删除
2，在线添加，扩展，删除和重命名列
3，超高压缩比，最高25倍的压缩比
4，一个表可以包含多个聚簇索引
5，完全支持ACID事物的四大特性
Online DDL对比
通过对比可见：
1， 在字段的修改方面TokuDB有非常明显的优势，这大大方便了对大表的维护工作
2，因为TokuDB索引文件独立于数据文件，因此TokuDB删除索引的同时会释放表空间
存储空间对比（该测试表记录 2076884 ）
表结构：
CREATE TABLE `toku` (`pid` varchar(32) NOT NULL DEFAULT '',`CREATETIME` datetime NOT NULL,`UPDATETIMES` datetime NOT NULL,`USER_ID` bigint(20) NOT NULL,`HOMEWORK_ID` varchar(255) DEFAULT NULL,`COMPLETE_PRACTICE` int(11) NOT NULL DEFAULT '0',`note` varchar(257) NOT NULL DEFAULT '',`CLAZZ_ID` bigint(20) NOT NULL DEFAULT '0',`score` int(11) NOT NULL DEFAULT '0',`NOTE_CHECKEDS` bit(1) NOT NULL DEFAULT b'0',PRIMARY KEY (`pid`)
)
通过上图可见InnoDB和TokuDB存储空间的相差大概7倍，即TokuDB大大节省了存储空间。
响应时间对比
从原理上来说TokuDB是压缩存储，故响应时间上肯定要比InnoDB要慢，通过上图可见TokuDB的平均响应时间大概是InnoDB的2倍左右，不过按TokuDB的适用场景（存储非热点数据）来看着这算不上什么缺点。
同理可以参考：
QPS及TPS的对比
通过上述两个图的对比可见：TokuDB 的qps和tps 平均大概是InnoDB的一半左右，当然TokuDB的适用场景并不是高并发场景，该测试只是做一个对比。
总结：
TokuDB优点
1，online ddl 非常给力，特别是对字段的修改非常快
2，压缩比非常高通常都能达到7,8倍的压缩比
3，完全支持ACID事物的四大特性
TokuDB缺点
1，响应时间相对较长
2，online ddl 对text,blob等类型的字段不适用
3，没有合适的备份工具，只能通过mysqldump进行逻辑备份
建议适用场景：
1，访问频率不高的数据或历史数据归档
2，表非常大并且时不时还需要进行ddl操作
