mysql engine: tokudb介绍

TokuDB 是 MySQL 的一种高性能存储引擎，最早由 Tokutek 开发，后被 Percona 集成到 MariaDB / Percona Server中。

核心特点

• Fractal Tree Index（分形树索引）
• 大规模写入优化
• 高压缩比
• 降低随机 IO
• 适合写密集型场景

它本质上是 InnoDB 的替代存储引擎。

---

1.TokuDB 核心原理

1.1 B+Tree vs Fractal Tree

传统 InnoDB：

INSERT
  -> 修改页
  -> Page Split
  -> 随机IO增加

TokuDB：

INSERT
  -> 写入 Message Buffer
  -> 延迟合并
  -> 批量刷盘

1.2 Fractal Tree 架构

flowchart TD
    A[Client Write] --> B[Root Buffer]
    B --> C[Internal Node Buffer]
    C --> D[Leaf Node]
    D --> E[Disk]

    B -.延迟批量下推.-> C
    C -.批量Merge.-> D

核心思想：

• 不立即修改叶子节点
• 采用消息缓冲（Message Buffer）
• 延迟批量合并
• 极大减少随机写放大

---

2.TokuDB 的优势

2.1 超强写入性能

尤其适合：

• 日志平台
• 时序数据
• 审计系统
• 大批量导入
• 高并发 INSERT

典型场景：

INSERT INTO log_table VALUES (...)

百万级 TPS 场景下：
TokuDB 通常比 InnoDB 更省 IO。

---

2.2 高压缩比

TokuDB 支持：

• zlib
• quicklz
• lzma

压缩率：

引擎	压缩率
InnoDB	2~3x
TokuDB	5~10x

适合：

• TB/PB 级数据
• 冷热混合数据
• 归档型业务

---

2.3 大数据量索引维护优秀

传统 InnoDB：

索引越多
-> 写放大越严重
-> Page Split 越频繁

TokuDB：

延迟索引更新
-> 批量Merge
-> 更低随机IO

因此：

• 多索引场景收益明显
• 大表收益明显

---

3.TokuDB 的缺点

3.1 更新/删除不一定更快

虽然写入强，但：

UPDATE
DELETE

复杂场景下：

• Message Merge 成本高
• 后台 Compaction 压力大

可能出现：

• 延迟抖动
• CPU 升高

---

3.2 不适合高频短事务 OLTP

例如：

• 电商订单
• 高频点查
• 高频 update by primary key

因为：

• Fractal Tree 对 point lookup 不如 InnoDB 成熟
• Buffer 管理复杂

---

3.3 已基本退出主流生态

关键点：

• MySQL 8 已不支持
• Percona Server 8 移除
• MariaDB 新版本弱化
• 社区活跃度低

实际上：

TokuDB 已进入“历史引擎”阶段。

当前主流：

• InnoDB
• RocksDB
• TiKV
• WiredTiger
• ColumnStore

---

4.Aliyun RDS MySQL 中的 TokuDB

4.1 阿里云历史支持情况

阿里云早期部分 RDS MySQL 版本：

• MySQL 5.6
• Percona 系列

曾支持：

ENGINE=TokuDB

但后续逐步下线。

当前主流 RDS 基本：

• 不再默认支持
• 新实例无法启用
• 已不推荐使用

---

4.2 查看是否支持

SHOW ENGINES;

如果存在：

TokuDB | YES

说明可用。

---

4.3 创建 TokuDB 表

CREATE TABLE test (
    id BIGINT PRIMARY KEY,
    name VARCHAR(128)
) ENGINE=TokuDB;

---

5.TokuDB 与 InnoDB 对比

特性	InnoDB	TokuDB
B+Tree	是	否
Fractal Tree	否	是
高频写入	中	强
压缩率	中	高
OLTP	强	一般
点查	强	一般
大规模导入	一般	强
生态支持	强	弱
MySQL8	支持	不支持

---

6.为什么 TokuDB 没落

6.1 SSD 改变了世界

TokuDB 最初解决：机械硬盘随机IO差。

但 SSD 出现后：

• 随机 IO 成本骤降
• InnoDB 获得巨大提升

TokuDB 优势被削弱。

---

6.2 RocksDB 崛起

LSM Tree 更适合：

• SSD
• WAL
• 时序
• KV

代表：

• RocksDB
• TiKV
• CockroachDB

逐渐替代 TokuDB。

---

6.3 MySQL 官方生态封闭

Oracle MySQL：

• 主要维护 InnoDB
• 第三方引擎生存空间变小

导致：

• TokuDB 维护困难
• 兼容性下降