当前位置：首页 > news >正文

MySQL存储引擎InnoDB、MyRocks、NDB Cluster和未来架构

news 2026/7/7 9:50:05

MySQL 的存储引擎是插件化的, MySQL 把 SQL 层和存储层解耦

SQL 解析 → 优化器 → 执行器 ↕ (插件化接口) 存储引擎层 (InnoDB / MyRocks / NDB / ...)

为MySQL表指定不同的存储引擎

CREATE TABLE my_table ( id INT PRIMARY KEY, data VARCHAR(255)) ENGINE=RocksDB;

一、InnoDB

InnoDB 的 B+Tree 架构就不太适合场景

每天数十亿条日志写入，磁盘 IO 成为瓶颈；
冷数据占据 80% 存储空间，成本居高不下；
跨地域高可用集群，要求毫秒级故障切换；

当你的瓶颈明确落在存储层，且InnoDB 的 B+Tree 特性恰好是瓶颈的根源时，才值得考虑替代方案。

二、MyRocks

MyRocks 是 Facebook（现 Meta）开源的 MySQL 存储引擎，底层基于RocksDB——一个用 C++ 编写的嵌入式键值存储库，而 RocksDB 的底层数据结构是LSM-Tree（Log-Structured Merge-Tree）。LSM-Tree与 InnoDB 的 B+Tree 是完全不同的流派。

LSM-Tree 的核心思想是把随机写变成顺序写，InnoDB 使用 B+Tree，数据按主键顺序组织在页中。当发生写入时：·如果目标页不在内存中，需要随机读磁盘加载该页；·修改后，页变为"脏页"，由后台刷盘线程随机写回磁盘

LSM-Tree 的思路

写入请求 ↓ MemTable (内存有序结构) ↓ (写满后，顺序刷盘) SST 文件 Level 0 (磁盘，不可变) ↓ (后台 Compaction 合并) SST 文件 Level 1 → Level 2 → ... → Level N

LSM-Tree与 InnoDB 的 B+Tree 的关键差异在于，所有写入先在内存中完成（MemTable），然后以顺序写的方式追加到磁盘上的 SST 文件；·磁盘上的数据分层存储，低层的数据通过后台 Compaction 逐步合并到高层。

MyRocks 的写入性能可以是 InnoDB 的 2~10 倍（具体取决于负载特征），因为它的磁盘 IO 几乎全是顺序的,MyRocks 的另一大杀手锏是存储空间效率.

由于 SST 文件是有序的、不可变的块，可以应用块级压缩算法（Snappy、ZSTD、LZ4 等）。在实际案例中，MyRocks 的数据压缩比通常能达到2:1 到 4:1，而 InnoDB 在默认配置下通常只有 1.5:1 左右的压缩效率。

Facebook 的真实数据：他们将部分 MySQL 实例从 InnoDB 迁移到 MyRocks 后，存储空间减少了50% 以上，同时写入延迟显著降低。对于管理 PB 级数据的团队，这意味着真金白银的成本节省。

没有免费的午餐。LSM-Tree 的代价是：

问题	原因	影响
读放大	一次查询可能需要查找多个 SST 文件	点查询比 InnoDB 慢（尤其无索引时）
写放大	Compaction 过程反复重写数据	持续大量写入时的后台开销
范围查询抖动	Compaction 期间可能阻塞读取	延迟的 P99 不稳定
事务能力	支持 MVCC 但实现不同于 InnoDB	复杂事务场景不如 InnoDB 成熟

MyRocks 场景

强烈推荐：

·高吞吐写入场景（IoT 时序数据、日志存储、用户行为埋点）

·数据量大、压缩需求高的场景（数据归档、冷热分层存储）

·写多读少的业务（写入:读取 > 5:1）

不太适合：

·大量随机点查询的 OLTP 核心业务

·依赖外键、全文索引的场景

·事务逻辑极复杂的金融系统

三、NDB Cluster：需求是高可用

NDB（Network DataBase）是 MySQL Cluster 的核心存储引擎，由 Oracle 维护。它与 InnoDB 和 MyRocks 的设计哲学完全不同——NDB 是一个分布式的、基于内存的、无共享（Shared-Nothing）架构。

内存优先 + 自动分片

NDB 的核心特征：

·数据主存储在内存中（也可配置磁盘持久化），读写延迟极低；

·自动水平分片：数据按主键哈希分布到多个数据节点（Data Node）；

·同步复制：每个数据分片有多个副本，事务在所有副本上同步提交；

·无单点故障：管理节点、数据节点、SQL 节点均可冗余部署。

架构示意：

应用层 ↓ SQL 节点 (mysqld) × N ← 无状态，任意扩展 ↓ 数据节点 (ndbd) × M ← 数据分片 + 副本 ↓ (心跳 + 自动故障转移) 管理节点 (ndb_mgmd) ← 集群配置管理

四、五、适用引擎场景

你的场景	推荐引擎	核心原因
通用 OLTP 业务	InnoDB	最成熟、生态最好、没有短板
海量写入 + 存储成本敏感	MyRocks	高写入吞吐 + 高压缩比
电信级高可用 + 低延迟	NDB Cluster	内存架构 + 同步复制
全文检索需求	InnoDB (或上 Elasticsearch)	InnoDB 支持全文索引
时序/日志/埋点	MyRocks (或上 ClickHouse)	LSM-Tree 天然适合追加写
跨地域容灾	NDB 或 Galera	同步复制保证一致性