MySQL NDB事件订阅和普通SQL查询有什么区别

我第一次把 NDB Cluster 的变更同步需求拆出来时，容易把“查到一行数据”和“知道某一行刚刚发生变化”当成同一件事。实际上，普通 SQL 查询是应用主动发起读取，NDB 事件订阅则是应用先注册感兴趣的表事件，再从事件队列中等待变化。前者回答“现在是什么”，后者回答“刚刚发生了什么”。

官方地址：https://dev.mysql.com/doc/ndbapi/en/ndb-examples-event-handling.html

简单判断：需要“把当前符合条件的行读出来”，用 SQL；需要“在数据变化时收到通知”，用 NDB API 事件订阅。生产系统常常两者一起用：事件负责低延迟触发，SQL 负责启动时补数和异常恢复。

先把 SQL 节点和 NDB API 的边界分开

MySQL NDB Cluster 里的 SQL 节点，本质上是连接数据节点的 MySQL Server，应用通过它提交标准 SQL 并接收行结果。NDB API 则允许应用绕过 MySQL Server，直接使用面向对象的事务、扫描和事件接口访问集群。两者都能访问 NDB 数据，但调用方向并不一样：SQL 查询由调用方主动发起，事件订阅由调用方先建立长期关系，再等待数据节点报告变化。

因此，下面两段操作虽然都和同一张表有关，语义却不同：

-- SQL 查询主动读取当前快照；结果只属于这一次请求。
SELECT order_id, status
FROM orders
WHERE status = 'ready';

// NDB API 先订阅事件，后续由事件循环接收表变化。
NdbEventOperation* op = ndb->createEventOperation("orders_changed");
// createEventOperation 失败时不能继续使用空指针。
if (op == nullptr) {
    return reportNdbError(ndb->getNdbError());
}

一次性结果集和持续事件流，差异到底在哪里

普通 SQL 查询的生命周期短：建立连接、发送语句、读取结果集、关闭结果集。它可以表达复杂的过滤、排序和聚合，读者拿到的是查询时刻符合条件的行。即使表随后发生变化，这次结果也不会自动追加新行。

事件订阅的生命周期长：先创建数据库事件定义，再创建事件操作对象，激活后持续轮询事件。事件通常携带表事件类型、epoch，以及变更前后的列值读取入口。它更像一个变化通知通道，不适合替代任意条件查询；例如“把过去七天所有 ready 订单按金额排序”仍然应该交给 SQL。

建立事件订阅时，真正需要记住的调用关系

官方 NDB API 的核心顺序可以压缩成四步：用已创建的事件名称调用 createEventOperation，为事件操作绑定需要读取的列，执行订阅，然后在事件循环中读取事件。NDB 7.4 以后，事件 API 引入了 epoch 驱动的接口；新代码应优先理解 getEventType2、getEpoch 和对应的新版事件读取方法，不要把旧的 GCI 或已弃用方法当成唯一写法。

// 这是调用关系示意：事件名必须对应已经创建的 Event。
NdbEventOperation* op = ndb->createEventOperation("orders_changed");
if (op == nullptr) {
    return reportNdbError(ndb->getNdbError());
}

// execute 激活当前订阅；失败时应记录 NDB 错误并停止消费。
if (op->execute() != 0) {
    return reportNdbError(op->getNdbError());
}

// 事件循环只处理已到达的事件，不把它误当成一次 SELECT 结果集。
while (NdbEventOperation* current = ndb->nextEvent2()) {
    auto type = current->getEventType2();
    auto epoch = current->getEpoch();
    handleChange(type, epoch, current);
}

// 停止订阅后仍需按官方生命周期继续排空事件缓冲区，再释放资源。
if (ndb->dropEventOperation(op) != 0) {
    return reportNdbError(ndb->getNdbError());
}

这段代码是接口关系示意，不代表可以不补齐连接初始化、事件定义、列绑定和错误处理就直接编译。关键是不要把 nextEvent2 设计成“执行一次就返回全部数据”的函数：它读取的是队列中的事件；如果应用需要完整当前状态，仍应另发 SQL 查询。

普通 SQL 适合做补数，ndbinfo 适合观察订阅状态

实际项目里我更愿意把 SQL 放在两个位置：启动时根据业务边界做一次初始扫描，或者在事件消费失败后按主键、epoch 记录和业务时间窗补齐数据。事件通道只负责把变化尽快送到处理器，不承担无限期保存所有历史变化的职责。

排查订阅时，可以从 NDB 的信息表观察事件订阅记录：

-- ndbinfo.events 用于查看事件订阅与表事件类型；它是观察入口，不是事件消费器。
SELECT event_id, name, table_id, reporting, columns, table_event
FROM ndbinfo.events
WHERE name = 'orders_changed';

如果查询结果为空，不要立即认为“表没有变化”。要分开判断：事件定义是否存在、API 节点是否成功建立操作、订阅是否已经执行、消费循环是否持续运行。对于 SQL 快照，则要记录查询条件、读到的最大主键或业务时间边界，让后续补数有明确的起点。

恢复和版本边界不能靠一次查询掩盖

NDB API 文档明确指出，使用 ndb_restore 恢复集群后，API 事件订阅不会自动持久化，应用必须显式重建订阅。这个边界是普通 SQL 查询没有的：SQL 客户端可以重新连接并再次执行语句，但事件消费者还要重新创建事件操作、重新激活，并设计恢复期间的补数区间。

事件循环还要处理空 epoch、异常 epoch 和缓冲区压力。新版接口中的事件类型不是只有 INSERT、UPDATE、DELETE；遇到不一致或内存相关的异常状态时，应该把它当作恢复信号，暂停盲目确认，记录最后已处理的 epoch，再通过 SQL 或业务日志完成核对。事件消费“没有报错”不等于“没有漏事件”。

几个相关问题

NDB 事件订阅能不能完全替代 SELECT？

不能。事件适合通知变化，SELECT 适合读取快照、复杂条件和补数。可靠方案通常把两者组合起来。

事件订阅是不是自动保存历史记录？

不应这样假设。应用要负责消费、落库或确认事件，并为重启、恢复和缓冲区异常准备补数路径。

为什么 SQL 查询能看到数据，事件却没有收到？

可能是查询走的是当前快照，而事件定义、事件操作、激活状态或消费循环存在问题；先查 ndbinfo.events，再检查 API 节点的订阅生命周期。

普通 MySQL 表也能用 NDB API 事件接口吗？

NDB API 事件接口面向 NDB Cluster 的事件模型，不能把它当成任意 MySQL 存储引擎的通用订阅机制。先确认目标表和集群确实使用 NDB。

我的选择清单

需要“当前数据是什么”时选 SQL；需要“变化发生就触发处理”时选事件订阅；需要可靠同步时采用“事件低延迟消费 + SQL 可重放补数”的组合。只要把快照、变化通知和恢复边界分开，MySQL NDB 事件订阅与普通 SQL 查询就不会再被误认为是两种写法相近的同一接口。