MySQL 的存储引擎是插件化的, MySQL 把 SQL 层和存储层解耦SQL 解析 → 优化器 → 执行器 ↕ (插件化接口) 存储引擎层 (InnoDB / MyRocks / NDB / ...)为MySQL表指定不同的存储引擎CREATE TABLE my_table ( id INT PRIMARY KEY, data VARCHAR(255)) ENGINERocksDB;一、InnoDBInnoDB 的 BTree 架构就不太适合场景每天数十亿条日志写入磁盘 IO 成为瓶颈冷数据占据 80% 存储空间成本居高不下跨地域高可用集群要求毫秒级故障切换当你的瓶颈明确落在存储层且InnoDB 的 BTree 特性恰好是瓶颈的根源时才值得考虑替代方案。二、MyRocksMyRocks 是 Facebook现 Meta开源的 MySQL 存储引擎底层基于RocksDB——一个用 C 编写的嵌入式键值存储库而 RocksDB 的底层数据结构是LSM-TreeLog-Structured Merge-Tree。LSM-Tree与 InnoDB 的 BTree 是完全不同的流派。LSM-Tree 的核心思想是把随机写变成顺序写InnoDB 使用 BTree数据按主键顺序组织在页中。当发生写入时·如果目标页不在内存中需要随机读磁盘加载该页·修改后页变为脏页由后台刷盘线程随机写回磁盘LSM-Tree 的思路写入请求 ↓ MemTable (内存有序结构) ↓ (写满后顺序刷盘) SST 文件 Level 0 (磁盘不可变) ↓ (后台 Compaction 合并) SST 文件 Level 1 → Level 2 → ... → Level NLSM-Tree与 InnoDB 的 BTree 的关键差异在于所有写入先在内存中完成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需求是高可用NDBNetwork 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 ... ENGINExxx就能搞定的。它涉及·功能兼容性验证索引类型、SQL 语法、事务隔离级别·性能基准测试不是你想象的负载是你的实际负载·运维体系调整备份恢复、监控告警、扩容策略·团队学习成本。Facebook 从 InnoDB 切 MyRocks 花了数年时间从内部验证到逐步灰度才完成迁移——这本身就是一个信号换引擎是战略决策不是临时优化Amazon Aurora 和阿里云 PolarDB 已经证明了存算分离的可行性计算节点只处理 SQL 逻辑数据下沉到共享存储层。这种架构下传统意义上由引擎承担的数据持久化工作被剥离引擎层变得更轻、更专注于计算优化。
