MySQL存储引擎InnoDB、MyRocks、NDB Cluster和未来架构
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 NLSM-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 | 同步复制保证一致性 |
一个核心原则
InnoDB 不满足需求，在换引擎。
换引擎不是一句ALTER TABLE ... ENGINE=xxx就能搞定的。它涉及：
·功能兼容性验证（索引类型、SQL 语法、事务隔离级别）；
·性能基准测试（不是你想象的负载，是你的实际负载）；
·运维体系调整（备份恢复、监控告警、扩容策略）；
·团队学习成本。
Facebook 从 InnoDB 切 MyRocks 花了数年时间，从内部验证到逐步灰度才完成迁移——这本身就是一个信号：换引擎是战略决策，不是临时优化
Amazon Aurora 和阿里云 PolarDB 已经证明了"存算分离"的可行性：计算节点只处理 SQL 逻辑，数据下沉到共享存储层。这种架构下，传统意义上由"引擎"承担的数据持久化工作被剥离，引擎层变得更轻、更专注于计算优化。