客户端接收线程只有在高负载时才启用，判断“高负载”的标准是在轮询队列（接收队列）中等待的客户端数量大于 min_active_clients_recv_thread（默认值：） 8。

这是确定高负载的糟糕指标，因为单个客户端（例如处理传入复制事件的二进制日志注入器线程）本身也可能会遇到高负载。推送连接查询也是如此（其中接收到非常大批量的传入TRANSID_AI信号）。

我们更改接收线程，使其现在在轮询队列中休眠而不是完全停用，因此它现在始终可用于处理传入信号，即使客户端负载不高。（缺陷号 33752914）

重要更改：服务器选项 支持的最大值 --ndb-batch-size已从31536000增加到 2147483648(2 GB)。（缺陷号 21040523）

性能： 在同一事务中向空表或小表中插入大量行时，插入行的速率迅速下降到初始速率的 50% 以下；随后，发现大约 50% 的 CPU 时间花在了 上Dbacc::getElement()，确定的根本原因是调整用于存储元素的结构大小的时间 DBACC，随着在同一事务中插入更多行而增长，并缩小提交后。

我们通过检查是否需要在插入或删除元素后立即调整大小来解决此问题。这也处理随后拒绝插入。（缺陷号 33803487）

参考资料：另请参阅：错误 #33803541。

性能： 内部函数computeXorChecksum() 的实现非常小心，以帮助编译器生成最佳代码，但发现它消耗过多的 CPU 资源，并且性能不如更简单的实现。XOR这个函数现在用一个循环对数组的结果进行总结来重新实现（缺陷号 33757412）

在某些情况下，NDB没有正确验证数据节点的所有节点 ID。（缺陷号 33896409）

在某些情况下，数组索引没有得到正确处理。（错误#33896389，错误#33896399，错误#33916134）

NdbEventBuffer非字符数据的哈希键生成重复使用了相同的 256 个哈希键；此外，在计算散列键时忽略零长度的字符串。（缺陷号 33783274）

基于 EventBytesRecvdCount事件计数器的 NDB API 统计信息的收集产生了过多的开销。现在这个计数器使用一个在事件缓冲区被填充时聚合的值来更新，而不是在一个单独的函数调用中遍历所有事件缓冲区数据。

有关详细信息，请参阅 NDB API 统计计数器和变量。（缺陷号 33778923）

接收线程 ID 在内部方法中进行了硬编码， TransporterFacade::raise_thread_prio()因此它始终会提高接收线程的优先级，即使是从发送线程调用时也是如此。（缺陷号 33752983）

ndbd 的弃用-r选项 已被删除。此外，此更改还从 ndbd的输出中删除了无关的文本。（缺陷号 33362935） --help

参考资料：另请参阅：Bug #31565810。

ndb_import工具只处理隐藏的主键，NDB当表没有显式主键时定义。这导致在插入包含NULL 自动递增主键列的行时出错，即使同一行已被接受 LOAD DATA INFILE。

我们通过添加对导入具有NULL自动增量主键列中的一个或多个实例的表的支持来解决此问题。这包括检查一张表是否只有一个自动增量列；如果此列可以为空，则由ndb_import重新定义为 （缺陷号 30799495）NOT NULLNULLNDB

当检测到节点故障时，与该节点位于同一节点组中的幸存节点会尝试将任何缓冲的更改数据重新发送给事件订阅者。在没有未完成的 epoch 交付的情况下，即未确认的 GCI 列表为空，幸存的节点错误地假设该列表永远不会为空。（缺陷号 30509416）