ndb集群是独立部署的内存型分布式数据库系统，mysql server仅为sql接入层；需用mysql cluster版本、启用--ndbcluster参数、主键强制显式定义、数据节点存数据、sql节点无本地数据、join性能依赖分区键命中。

NDB 集群不是 MySQL 的“分布式存储插件”，它是一套独立部署、强耦合的内存型分布式数据库系统，MySQL Server 只是它的 SQL 接入层；直接在现有 MySQL 上启用 ENGINE=NDB 不等于搭好了分布式存储。

为什么 CREATE TABLE ... ENGINE=NDB 总是报错 Unknown storage engine 'NDB'

这是最常见误解的起点：NDB 不是随 MySQL 二进制包默认启用的引擎。MySQL 官方编译版（尤其是 yum/apt 安装的）默认不带 NDB 支持，mysqld 进程根本没加载对应模块。

• 必须使用 MySQL Cluster 版本（即 mysql-cluster-community-server），而非普通 mysql-server
• 确认 mysqld 启动时加载了 --ndbcluster 参数，且配置文件中包含 ndbcluster 和 ndb-connectstring
• SHOW ENGINES; 输出里 NDB 行的 Support 列必须是 YES，不是 NO 或 DISABLED
• 即使启用了，CREATE TABLE 仍可能失败——NDB 要求主键必须显式定义，且不能为 NULL；TEXT/BLOB 列不支持（除非用 LONG VARCHAR 替代）

ndb_mgmd、ndbd、mysqld 三个进程到底谁存数据、谁管 SQL

NDB 是“计算与存储分离”的典型设计，但分工和依赖比想象中更刚性：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

• ndb_mgmd 是管理节点，只存集群配置，不存业务数据；停掉它不影响查询，但无法增删节点或在线改表结构
• ndbd（或新版 ndbmtd）是数据节点，真正存表数据（全内存，可配持久化日志）；至少 2 个才能保证高可用，单点故障即丢数据
• mysqld 是 SQL 节点，无本地数据，所有 DML/DDL 请求都转发给 ndbd；它挂了不影响数据安全，但客户端连不上 SQL 接口
• 三者必须版本严格对齐（比如都是 8.0.33-ndb-8.0.33），混用小版本会导致连接拒绝或静默数据截断

为什么简单 JOIN 查询变慢，甚至超时

NDB 对跨数据节点操作极其敏感，SQL 节点不是“智能路由”，而是按分区键硬拆请求：

• 没指定分区键（如 PRIMARY KEY 或 SHARD KEY）的 JOIN，会被广播到所有数据节点执行，再由 mysqld 汇总结果——网络+CPU 开销指数级增长
• WHERE 条件中若没命中分区键，同样触发全节点扫描；NDB 不支持索引下推到数据节点外的二级索引（ONLINE ALTER 创建的除外）
• 大结果集 SELECT * 容易撑爆 mysqld 内存，因为 NDB 返回的是行数据流，不支持游标分页；必须用 LIMIT + 合理 ORDER BY 控制返回量
• 事务默认隔离级别是 READ COMMITTED，不支持 SELECT ... FOR UPDATE 在非主键条件上加锁，容易出现幻读

真正难的不是启动集群，而是把业务逻辑适配到 NDB 的数据分布模型里：主键即分片键、避免跨分片 JOIN、接受最终一致性、容忍 SQL 层功能阉割（比如没有外键、视图不可更新、子查询限制多）。没做过数据建模迁移就上 NDB，大概率是用分布式代价换来了更差的性能和更高的运维复杂度。