MySQL8 中文参考（九十五）（mysql8.0中文手册）

原文：docs.oracle.com/javase/tutorial/reallybigindex.html

原文：dev.mysql.com/doc/refman/8.0/en/mysql-cluster-disk-data-storage-requirements.html

25.6.11.2 NDB 集群磁盘数据存储要求

以下各项适用于磁盘数据存储要求：

具有可变长度列的磁盘数据表占用固定空间。对于每一行，这等于存储该列的最大值所需的空间。

有关计算这些值的一般信息，请参阅数据类型的存储要求。

您可以通过查询信息架构文件表来估计数据文件和撤消日志文件中的可用空间量。有关更多信息和示例，请参阅INFORMATION_SCHEMA FILES 表。

消息

OPTIMIZE TABLE 语句对磁盘数据表没有影响。

磁盘数据表将TEXT 或BLOB 列的前256 字节存储在内存中，仅将剩余部分存储在磁盘上。

磁盘数据表中的每一行使用内存中的8个字节来指向存储在磁盘上的数据。这意味着在某些情况下，将内存列转换为基于磁盘的格式实际上会增加内存使用量。例如，将CHAR(4) 列从基于内存的格式转换为基于磁盘的格式会将每行使用的DataMemory 从4 字节增加到8 字节。

重要提示

使用–initial 选项启动集群不会删除磁盘数据文件。在执行集群的首次重新启动之前，您必须手动删除这些文件。

通过确保DiskPageBufferMemory 足够大，您可以最大限度地减少磁盘寻道次数并提高磁盘数据表的性能。要确定是否需要增加该参数的值，请查询diskpagebuffer表。

25.6.12 NDB 集群中的在线 ALTER TABLE 操作

翻译：dev.mysql.com/doc/refman/8.0/en/mysql-cluster-online-operations.html

MySQL NDB Cluster 8.0 支持使用ALTER TABLE . ALGORITHM=DEFAULT|INPLACE|COPY 进行在线表架构更改。 MySQL Cluster 处理COPY 和INPLACE，如以下段落所述。

当ALGORITHM=COPY 时，mysqld NDB 集群处理程序执行以下操作：

指示数据节点创建表的空副本并对此副本进行必要的架构更改。

从原始表中读取行并将其写入副本。

指示数据节点删除原始表并重命名副本。

这有时称为“复制”或“离线”ALTER TABLE。

DML 操作不能与复制的ALTER TABLE 同时运行。

发出复制ALTER TABLE 语句的mysqld 获取元数据锁，该锁仅对该mysqld 有效。其他NDB 客户端可能会在ALTER TABLE 复制过程中修改行数据，从而导致不一致。

如果指定ALGORITHM=INPLACE，NDB 集群处理程序将指示数据节点进行必要的更改，并且不执行数据复制。

这也称为“非复制”或“在线”ALTER TABLE。

非复制ALTER TABLE 允许并发DML 操作。

NDB 8.0 不支持ALGORITHM=INSTANT。

无论使用哪种算法，mysqld 在执行ALTER TABLE 时都会获取全局模式锁（GSL）。这可以防止（其他）DDL 或备份在此节点或集群中的其他SQL 节点上同时运行。通常这不是问题，除非ALTER TABLE 需要很长时间。

消息

一些旧的NDB cluster 版本使用NDB 特定的语法进行在线ALTER TABLE 操作。该语法已被删除。

在NDB 表中的可变宽度列上添加和删除索引是在线完成的。在线操作不涉及复制，因此不需要重新索引。 MySQL 集群中由其他API 节点访问的表不会被锁定（但请参阅本节后面的NDB 在线操作的限制）。这些操作不需要单用户模式来修改具有多个API 节点的NDB 集群中的NDB 表。在线DDL 操作期间事务可以继续不间断。

ALGORITHM=INPLACE 允许您对NDB 表执行在线ADD COLUMN、ADD INDEX（包括CREATE INDEX 语句）和DROP INDEX 操作。还支持NDB 表的在线重命名（在NDB 8.0 之前，无法在线重命名此类列）。

无法在线将基于磁盘的列添加到NDB 表。这意味着，当您使用表级STORAGE DISK 选项将内存中列添加到NDB 表时，必须显式声明新列使用基于内存的存储。例如，假设您创建了—— 个表空间ts1——。假设您已创建表t1，如下所示：

mysql 创建表t1 (

c1 INT NOT NULL 主键，

c2 VARCHAR(30)

）

表空间ts1 存储磁盘

发动机NDB；

查询正常，0 行受影响（1.73 秒）

记录： 0 重复： 0 警告： 0

您可以在线向该表添加新的内存列，如下所示：

mysql 更改表t1

ADD COLUMN c3 INT COLUMN_FORMAT 动态存储内存，

算法=就地；

查询正常，0 行受影响（1.25 秒）

记录： 0 重复： 0 警告： 0

如果省略STORAGE MEMORY 选项，该语句将失败。

mysql 更改表t1

添加列c4 INT COLUMN_FORMAT DYNAMIC，

算法=就地；

错误1846 (0A000): 不支持ALGORITHM=INPLACE。

不支持在线添加列或添加/重新组织分区。

算法=复制。

如果省略COLUMN_FORMAT DYNAMIC 选项，则会自动使用动态列格式并显示警告，如下所示：

mysql ALTER ONLINE TABLE t1 ADD COLUMN C4 INT STORAGE MEMORY;

查询正常，0 行受影响，1 条警告（1.17 秒）

记录： 0 重复： 0 警告： 0

mysql 显示警告\\G

************************** 1\\. 行****************** * **********

: 级警告

代码： 1478

消息：不支持带有存储磁盘的动态列c4。不支持列。

固定的

mysql 显示创建表t1\\G

************************** 1\\. 行****************** * **********

表： T1

创建表： CREATE TABLE `t1` (

`c1` int(11) NOT NULL,

`c2` varchar(30) 默认NULL，

`c3` int(11) /*!50606 存储内存*//*!50606 COLUMN_FORMAT DYNAMIC */默认NULL,

`c4` int(11) /*!50606 存储内存*/默认NULL,

主键（`c1`）

) /*!50606 TABLESPACE ts_1 存储磁盘*/ENGINE=ndbcluster DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci 集合中的1 行（0.03 秒）

消息

STORAGE 和COLUMN_FORMAT 关键字仅在MySQL Cluster 中受支持；任何在CREATE TABLE 或ALTER TABLE 语句中使用它们的尝试都会导致其他版本的MySQL 出现错误。

您还可以在NDB 表上使用语句ALTER TABLE . REORGANIZE PARTITION, ALGORITHM=INPLACE，而不指定*partition_names* INTO (*partition_settings*) 选项。您可以使用它在集群中新添加的数据节点之间在线重新分配MySQL 集群数据。这将导致不执行优化。优化需要OPTIMIZE TABLE 或空ALTER TABLE 语句。有关更多信息，请参见第25.6.7节“在线添加MySQL集群数据节点”。

NDB 在线操作的限制

不支持在线DROP COLUMN 操作。

以下限制适用于添加列或添加或删除索引的在线ALTER TABLE、CREATE INDEX 或DROP INDEX 语句：

在给定的在线ALTER TABLE 中只能使用ADD COLUMN、ADD INDEX 或DROP INDEX 之一。您可以使用一条语句在线添加一或多列，但只能使用一条语句创建或删除一个索引。

当您执行在线ALTER TABLE ADD COLUMN、ADD INDEX 或DROP INDEX（或CREATE INDEX 或DROP INDEX 语句）时，正在更改的表将不会被锁定到执行在线操作的API 节点之外。但是，当在线操作正在运行时，该表将被锁定，以防止在同一API 节点上启动的其他操作。

正在修改的表必须具有显式主键。 NDB 存储引擎创建的隐藏主键不足以实现此目的。

表使用的存储引擎不能在线更改。

表所使用的表空间不能在线更改。从NDB 8.0.21 开始，明确禁止像ALTER TABLE *ndb_table* . ALGORITHM=INPLACE, TABLESPACE=*new_tablespace* 这样的语句。（错误#99269、错误#31180526）

当与MySQL Cluster 磁盘数据表一起使用时，您无法在线更改列的存储类型（DISK 或MEMORY）。也就是说，在线方式添加或删除索引时，如果要更改列或列的存储类型，则必须在添加或删除索引的语句中使用ALGORITHM=COPY。

在线添加的列不能是BLOB 或TEXT 类型，并且必须满足以下条件：

列必须是动态的。也就是说，它必须使用COLUMN_FORMAT DYNAMIC 创建。如果省略COLUMN_FORMAT DYNAMIC 选项，则自动使用动态列格式。

该列必须允许空值，并且不能有除空之外的显式默认值。在线添加的列会自动创建为DEFAULT NULL，如下所示。

mysql 创建表t2 (

c1 INT NOT NULL AUTO_INCRMENT 主键

) 引擎=NDB;

查询正常，0 行受影响（1.44 秒）

mysql 更改表t2

添加列c2 INT，

添加列c3 INT，

算法=就地；

查询正常，0 行受影响，2 条警告（0.93 秒）

mysql 显示创建表t1\\G

************************** 1\\. 行****************** * **********

表： T1

创建Table: CREATE TABLE `t2` (

`c1` int(11) NOT NULL AUTO_INCRMENT,

`c2` int(11) 默认NULL,

`c3` int(11) 默认NULL,

主键（`c1`）

) ENGINE=ndbcluster DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci 集合中的1 行（0.00 秒）

必须在现有列之后添加列。如果您尝试在现有列之前在线添加列或使用FIRST 关键字，则该语句将失败并出现错误。

您无法对现有表列进行在线排序。

当在线添加列或在线创建或删除索引时，NDB 表上的在线ALTER TABLE 操作将固定格式列转换为动态格式，如下所示（为了清楚起见，此处显示的CREATE TABLE 和ALTER TABLE 是重复语句）。

mysql 创建表t2 (

c1 INT NOT NULL AUTO_INCRMENT 主键

) 引擎=NDB;

查询正常，0 行受影响（1.44 秒）

mysql 更改表t2

添加列c2 INT，

添加列c3 INT，

算法=就地；

查询正常，0 行受影响，2 条警告（0.93 秒）

显示mysql 警告；

************************** 1\\. 行****************** * **********

: 级警告

代码： 1478

Message: 将固定字段“c2”转换为动态字段以启用在线添加列

************************** 2\\. 行****************** * **********

: 级警告

代码： 1478

Message: 将固定字段“c3”转换为动态字段，以启用在线添加列2 行（0.00 秒）

仅在线添加或需要动态的列。不需要现有的列。这包括表的主键。这也可以修复，如下所示。

mysql 创建表t3 (

c1 INT NOT NULL AUTO_INCRMENT 主键COLUMN_FORMAT 固定

) 引擎=NDB;

查询正常，0 行受影响（2.10 秒）

mysql ALTER TABLE t3 ADD COLUMN C2 INT, ALGORITHM=INPLACE;

查询正常，0 行受影响，1 条警告（0.78 秒）

记录： 0 重复： 0 警告： 0

显示mysql 警告；

************************** 1\\. 行****************** * **********

: 级警告

代码： 1478

Message: 将固定字段“c2”转换为动态字段，以启用在线添加列1 行（0.00 秒）

重命名操作不会将列从FIXED 列格式转换为DYNAMIC 列格式。有关COLUMN_FORMAT 的更多信息，请参阅CREATE TABLE 语句。

使用ALGORITHM=INPLACE 在ALTER TABLE 语句中支持KEY、CONSTRAINT 和IGNORE 关键字。

不允许使用在线ALTER TABLE 语句将MAX_ROWS 设置为0。为此，您需要使用复制的ALTER TABLE。（错误#21960004）

25.6.13 权限同步和 NDB_STORED_USER

原文：dev.mysql.com/doc/refman/8.0/en/mysql-cluster-privilege-synchronization.html

NDB 8.0 引入了新机制，用于在连接到MySQL 集群的SQL 节点之间共享和同步用户、角色和权限。可以通过授予NDB_STORED_USER 权限来启用此功能。使用信息请参阅权限说明。

NDB_STORED_USER 像SHOW GRANTS 输出中的任何其他权限一样打印：

mysql 显示\’jon\’@\’localhost\’ 的补助金；

+———————————————— -+

| jon@localhost 授予|

+———————————————— -+

| 允许`jon`@`localhost` 使用*.*。

| 将*.* 上的NDB_STORED_USER 授予`jon`@`localhost` |

+———————————————— -+

您还可以使用MySQL Cluster 提供的ndb_select_all 实用程序验证此帐户的权限是否已共享，如下所示（某些输出被包装以保留格式）。

$ ndb_select_all -d mysql ndb_sql_metadata | grep \’`jon`@`localhost`\’

12 \’\’jon\’@\’localhost\’\’ 0 [NULL] \’允许*.* 被`jon`@`localhost`\’ 使用

11 \’\’jon\’@\’localhost\’\’ 0 2 \’创建用户`jon`@`localhost`

标识为“caching_sha2_password”

0x2441243030352466014340225A107D590E6E653B5D587922306102716D752E6656772F3038512F

6C5072776D30376D37347A384B557A4C564F70495158656A31382E45324E33

不需要密码过期默认帐户解锁密码历史记录默认

密码重用间隔默认密码需要当前默认值”

12 \’\’jon\’@\’localhost\’\’ 1 [NULL] \’将*.* 上的NDB_STORED_USER 授予`jon`@`localhost`\’

ndb_sql_metadata 是一个特殊的NDB 表，无法使用mysql 或其他MySQL 客户端查看。

授予NDB_STORED_USER 权限的语句，例如GRANT NDB_STORED_USER ON *.* TO \’cluster_app_user\’@\’localhost\’，指示NDB 使用查询SHOW CREATE USER cluster_app_user@localhost 和SHOW GRANTS FOR cluster_app_user@localhost 创建快照创建并保存。结果存储在ndb_sql_metadata中。其他SQL 节点将被要求读取并应用快照。每当MySQL 服务器启动并作为SQL 节点加入集群时，这些保存的CREATE USER 和GRANT 语句都会作为集群模式同步过程的一部分执行。

每当在原始SQL 节点以外的SQL 节点上执行SQL 语句时，该语句都会在NDBCLUSTER 存储引擎的实用程序线程中执行，该线程与MySQL 副本应用程序线程在相同的安全环境中运行。

从NDB 8.0.27 开始，执行用户权限更改的SQL 节点在执行前会获取全局锁，这可以防止不同SQL 节点上并发ACL 操作导致的死锁。在NDB 8.0.27 之前，使用NDB_STORED_USER 对用户的更改是完全异步更新的，无需获取锁。

请注意，共享模式更改操作是同步执行的，因此更改共享用户后，下一次共享模式更改将作为同步点。所有挂起的用户更改都在架构更改分发开始之前完成，然后架构更改本身会同步执行。例如，如果分布式用户的DROP USER 操作后跟DROP DATABASE 语句，则在所有SQL 节点完成删除该用户之前，数据库删除无法继续。

如果来自多个SQL 节点的多个GRANT、REVOKE 或其他用户管理语句导致不同SQL 节点上特定用户的权限发生冲突，则该用户在已知权限的SQL 节点上的权限为您可以通过以下方式解决该问题：发出GRANT NDB_STORED_USER。这个问题是正确的。这会获取新的权限快照并将其同步到其他SQL 节点。

MySQL Cluster 8.0 不支持像NDB 那样通过修改MySQL 权限表以使用NDB 存储引擎来跨MySQL Cluster 中的SQL 节点分配MySQL 用户和权限。

7.6 和之前的版本中一样（参见 Distributed Privileges Using Shared Grant Tables）。有关此更改对从先前版本升级到 NDB 8.0 的影响的信息，请参见 Section 25.3.7, “Upgrading and Downgrading NDB Cluster”。

25.6.14 NDB 集群的文件系统加密

原文：dev.mysql.com/doc/refman/8.0/en/mysql-cluster-tde.html

25.6.14.1 NDB 文件系统加密设置和使用

25.6.14.2 NDB 文件系统加密实现

25.6.14.3 NDB 文件系统加密限制

以下章节提供了关于NDB数据节点文件系统加密的信息，该加密方式在 NDB 8.0.31 及更高版本中实现。

译文：dev.mysql.com/doc/refman/8.0/en/mysql-cluster-tde-setup.html

25.6.14.1 NDB 文件系统加密设置和使用

文件系统加密：要启用先前未加密的文件系统的加密，需要执行以下步骤：

在config.ini文件的[ndbd default]部分中设置所需的数据节点参数，如下所示：
[ndbd default]
EncryptedFileSystem= 1
这些参数必须如所有数据节点所示设置。
使用–initial或–reload启动管理服务器，以使其读取更新后的配置文件。
执行所有数据节点的滚动初始启动（或重新启动）（参见第 25.6.5 节，“执行 NDB 集群的滚动重启”启动每个数据节点；此外，对每个数据节点进程提供–filesystem-password或–filesystem-password-from-stdin中的任一选项，以及密码。当您在命令行上提供密码时，会显示警告，类似于这样：
> ndbmtd -c 127.0.0.1 –filesystem-password=ndbsecret
ndbmtd: [Warning] Using a password on the command line interface can be insecure.
2022-08-22 16:17:58 [ndbd] INFO — Angel connected to \’127.0.0.1:1186\’
2022-08-22 16:17:58 [ndbd] INFO — Angel allocated nodeid: 5
–filesystem-password可以接受来自文件、tty或stdin的密码；–filesystem-password-from-stdin仅接受来自stdin的密码。后者保护密码免受在进程命令行或文件系统中暴露，并允许从另一个安全应用程序传递密码的可能性。
您还可以将密码放在一个my.cnf文件中，该文件可以被数据节点进程读取，但不能被系统的其他用户读取。使用与前面示例中相同的密码，文件的相关部分应如下所示：
[ndbd]
filesystem-password=ndbsecret
您还可以在my.cnf文件中使用–filesystem-password-from-stdin选项提示启动数据节点进程的用户在启动时提供加密密码，如下所示：
[ndbd]
filesystem-password-from-stdin
在这种情况下，当启动数据节点进程时，用户会被提示输入密码，如下所示：
> ndbmtd -c 127.0.0.1
Enter filesystem password: *********
2022-08-22 16:36:00 [ndbd] INFO — Angel connected to \’127.0.0.1:1186\’
2022-08-22 16:36:00 [ndbd] INFO — Angel allocated nodeid: 5
>
无论使用何种方法，加密密码的格式与用于加密备份密码的格式相同（参见第 25.6.8.2 节，“使用 NDB 集群管理客户端创建备份”或–filesystem-password-from-stdin。

文件系统解密：要从加密文件系统中删除加密，请执行以下操作：

在config.ini文件的[ndbd default]部分中，将EncryptedFileSystem = OFF设置为关闭。
使用–initial或–reload重新启动管理服务器。
执行数据节点的滚动初始重启。在重新启动节点二进制文件时，不要使用任何与密码相关的选项。
重新启动时，每个数据节点都会清除其磁盘上的状态，并以未加密形式重建。

要查看文件系统加密是否正确配置，可以使用针对ndbinfo config_values和config_params表的查询，类似于这样：

mysql> SELECT v.node_id AS Node, p.param_name AS Parameter, v.config_value AS Value
-> FROM ndbinfo.config_values v
-> JOIN ndbinfo.config_params p
-> ON v.config_param=p.param_number
-> WHERE p.param_name=\’EncryptedFileSystem\’;
+——+———————-+——-+
| Node | Parameter | Value |
+——+———————-+——-+
| 5 | EncryptedFileSystem | 1 |
| 6 | EncryptedFileSystem | 1 |
| 7 | EncryptedFileSystem | 1 |
| 8 | EncryptedFileSystem | 1 |
+——+———————-+——-+
4 rows in set (0.10 sec)

在这里，EncryptedFileSystem在所有数据节点上都等于1，这意味着文件系统加密已启用。

原文：dev.mysql.com/doc/refman/8.0/en/mysql-cluster-tde-implementation.html

25.6.14.2 NDB 文件系统加密实现

对于NDB透明数据加密（TDE），数据节点在静止状态下加密用户数据，安全性由密码（文件系统密码）提供，该密码用于加密和解密每个数据节点上的秘密文件。秘密文件包含一个节点主密钥（NMK），稍后用于加密用于持久性的不同文件类型。NDB TDE 加密用户数据文件，包括 LCP 文件、重做日志文件、表空间文件和撤销日志文件。

您可以使用ndbxfrm实用程序查看文件是否已加密，如下所示：

> ndbxfrm -i ndb_5_fs/LCP/0/T2F0.Data
File=ndb_5_fs/LCP/0/T2F0.Data, compression=no, encryption=yes
> ndbxfrm -i ndb_6_fs/LCP/0/T2F0.Data
File=ndb_6_fs/LCP/0/T2F0.Data, compression=no, encryption=no

从 NDB 8.0.31 开始，可以使用在该版本中添加的ndb_secretsfile_reader程序从秘密文件中获取密钥，如下所示：

> ndb_secretsfile_reader –filesystem-password=54kl14 ndb_5_fs/D1/NDBCNTR/S0.sysfile
ndb_secretsfile_reader: [Warning] Using a password on the command line interface can be insecure.
cac256e18b2ddf6b5ef82d99a72f18e864b78453cc7fa40bfaf0c40b91122d18

每个节点的密钥层次结构可以表示如下：

用户提供的口令（P）通过使用随机盐的密钥派生函数处理，生成一个唯一的口令密钥（PK）。
PK（对每个节点唯一）加密每个节点上的数据在其自己的秘密文件中。
秘密文件中的数据包括一个唯一的、随机生成的节点主密钥（NMK）。
NMK（使用包装）加密每个加密文件的头部中的一个或多个随机生成的数据加密密钥（DEK）值（包括 LCP 和 TS 文件以及重做和撤销日志）。
数据加密密钥值（DEK[0]，…，DEK[n]）用于加密每个文件中的[子集的]数据。

口令间接加密包含随机 NMK 的秘密文件，该文件加密节点上每个加密文件的一部分头。加密文件头包含用于该文件中数据的随机数据密钥。

加密由数据节点内的NDBFS层透明实现。NDBFS内部客户端块对其文件进行正常操作；NDBFS用额外的头部和尾部信息包装物理文件，支持加密，并在读取和写入文件时加密和解密数据。包装文件格式称为ndbxfrm1。

节点密码通过 PBKDF2 和随机盐处理，用于加密包含用于加密每个加密文件中的随机生成数据加密密钥的秘密文件。

加密和解密工作是在 NDBFS I/O 线程中执行的（而不是在信号执行线程中，如主线程、tc 线程、ldm 线程或 rep 线程）。这类似于压缩的 LCP 和压缩的备份的处理方式，通常会导致增加 I/O 线程的 CPU 使用率；您可能希望根据 I/O 线程的情况调整ThreadConfig。

原文：dev.mysql.com/doc/refman/8.0/en/mysql-cluster-tde-limitations.html

25.6.14.3 NDB 文件系统加密限制

NDB 集群中的透明数据加密受以下限制和限制：

文件系统密码必须提供给每个单独的数据节点。
文件系统密码轮换需要对数据节点进行初始滚动重启；这必须手动执行，或者由NDB外部应用程序执行。
对于仅具有单个副本的集群（NoOfReplicas = 1），需要进行完整备份和恢复以进行文件系统密码轮换。
所有数据加密密钥的轮换需要初始节点重新启动。

25.6.15 NDB API 统计计数器和变量

原文：dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndb-api-statistics.html

有多种类型的统计计数器与由Ndb对象执行或影响的操作相关联。这些操作包括启动和关闭（或中止）事务；主键和唯一键操作；表、范围和修剪扫描；线程在等待各种操作完成时被阻塞；以及由NDBCLUSTER发送和接收的数据和事件。在进行 NDB API 调用或将数据发送到数据节点或接收数据时，这些计数器在 NDB 内核内部递增。mysqld将这些计数器公开为系统状态变量；它们的值可以在SHOW STATUS的输出中读取，或通过查询性能模式session_status或global_status表来读取。通过比较操作NDB表的语句执行前后的值，您可以观察在 API 级别执行的相应操作，从而了解执行语句的成本。

您可以使用以下SHOW STATUS语句列出所有这些状态变量：

mysql> SHOW STATUS LIKE \’ndb_api%\’;
+———————————————-+———–+
| Variable_name | Value |
+———————————————-+———–+
| Ndb_api_wait_exec_complete_count | 297 |
| Ndb_api_wait_scan_result_count | 0 |
| Ndb_api_wait_meta_request_count | 321 |
| Ndb_api_wait_nanos_count | 228438645 |
| Ndb_api_bytes_sent_count | 33988 |
| Ndb_api_bytes_received_count | 66236 |
| Ndb_api_trans_start_count | 148 |
| Ndb_api_trans_commit_count | 148 |
| Ndb_api_trans_abort_count | 0 |
| Ndb_api_trans_close_count | 148 |
| Ndb_api_pk_op_count | 151 |
| Ndb_api_uk_op_count | 0 |
| Ndb_api_table_scan_count | 0 |
| Ndb_api_range_scan_count | 0 |
| Ndb_api_pruned_scan_count | 0 |
| Ndb_api_scan_batch_count | 0 |
| Ndb_api_read_row_count | 147 |
| Ndb_api_trans_local_read_row_count | 37 |
| Ndb_api_adaptive_send_forced_count | 3 |
| Ndb_api_adaptive_send_unforced_count | 294 |
| Ndb_api_adaptive_send_deferred_count | 0 |
| Ndb_api_event_data_count | 0 |
| Ndb_api_event_nondata_count | 0 |
| Ndb_api_event_bytes_count | 0 |
| Ndb_api_wait_exec_complete_count_slave | 0 |
| Ndb_api_wait_scan_result_count_slave | 0 |
| Ndb_api_wait_meta_request_count_slave | 0 |
| Ndb_api_wait_nanos_count_slave | 0 |
| Ndb_api_bytes_sent_count_slave | 0 |
| Ndb_api_bytes_received_count_slave | 0 |
| Ndb_api_trans_start_count_slave | 0 |
| Ndb_api_trans_commit_count_slave | 0 |
| Ndb_api_trans_abort_count_slave | 0 |
| Ndb_api_trans_close_count_slave | 0 |
| Ndb_api_pk_op_count_slave | 0 |
| Ndb_api_uk_op_count_slave | 0 |
| Ndb_api_table_scan_count_slave | 0 |
| Ndb_api_range_scan_count_slave | 0 |
| Ndb_api_pruned_scan_count_slave | 0 |
| Ndb_api_scan_batch_count_slave | 0 |
| Ndb_api_read_row_count_slave | 0 |
| Ndb_api_trans_local_read_row_count_slave | 0 |
| Ndb_api_adaptive_send_forced_count_slave | 0 |
| Ndb_api_adaptive_send_unforced_count_slave | 0 |
| Ndb_api_adaptive_send_deferred_count_slave | 0 |
| Ndb_api_wait_exec_complete_count_replica | 0 |
| Ndb_api_wait_scan_result_count_replica | 0 |
| Ndb_api_wait_meta_request_count_replica | 0 |
| Ndb_api_wait_nanos_count_replica | 0 |
| Ndb_api_bytes_sent_count_replica | 0 |
| Ndb_api_bytes_received_count_replica | 0 |
| Ndb_api_trans_start_count_replica | 0 |
| Ndb_api_trans_commit_count_replica | 0 |
| Ndb_api_trans_abort_count_replica | 0 |
| Ndb_api_trans_close_count_replica | 0 |
| Ndb_api_pk_op_count_replica | 0 |
| Ndb_api_uk_op_count_replica | 0 |
| Ndb_api_table_scan_count_replica | 0 |
| Ndb_api_range_scan_count_replica | 0 |
| Ndb_api_pruned_scan_count_replica | 0 |
| Ndb_api_scan_batch_count_replica | 0 |
| Ndb_api_read_row_count_replica | 0 |
| Ndb_api_trans_local_read_row_count_replica | 0 |
| Ndb_api_adaptive_send_forced_count_replica | 0 |
| Ndb_api_adaptive_send_unforced_count_replica | 0 |
| Ndb_api_adaptive_send_deferred_count_replica | 0 |
| Ndb_api_event_data_count_injector | 0 |
| Ndb_api_event_nondata_count_injector | 0 |
| Ndb_api_event_bytes_count_injector | 0 |
| Ndb_api_wait_exec_complete_count_session | 0 |
| Ndb_api_wait_scan_result_count_session | 0 |
| Ndb_api_wait_meta_request_count_session | 0 |
| Ndb_api_wait_nanos_count_session | 0 |
| Ndb_api_bytes_sent_count_session | 0 |
| Ndb_api_bytes_received_count_session | 0 |
| Ndb_api_trans_start_count_session | 0 |
| Ndb_api_trans_commit_count_session | 0 |
| Ndb_api_trans_abort_count_session | 0 |
| Ndb_api_trans_close_count_session | 0 |
| Ndb_api_pk_op_count_session | 0 |
| Ndb_api_uk_op_count_session | 0 |
| Ndb_api_table_scan_count_session | 0 |
| Ndb_api_range_scan_count_session | 0 |
| Ndb_api_pruned_scan_count_session | 0 |
| Ndb_api_scan_batch_count_session | 0 |
| Ndb_api_read_row_count_session | 0 |
| Ndb_api_trans_local_read_row_count_session | 0 |
| Ndb_api_adaptive_send_forced_count_session | 0 |
| Ndb_api_adaptive_send_unforced_count_session | 0 |
| Ndb_api_adaptive_send_deferred_count_session | 0 |
+———————————————-+———–+
90 rows in set (0.01 sec)

这些状态变量也可以从性能模式session_status和global_status表中获取，如下所示：

mysql> SELECT * FROM performance_schema.session_status
-> WHERE VARIABLE_NAME LIKE \’ndb_api%\’;
+———————————————-+—————-+
| VARIABLE_NAME | VARIABLE_VALUE |
+———————————————-+—————-+
| Ndb_api_wait_exec_complete_count | 617 |
| Ndb_api_wait_scan_result_count | 0 |
| Ndb_api_wait_meta_request_count | 649 |
| Ndb_api_wait_nanos_count | 335663491 |
| Ndb_api_bytes_sent_count | 65764 |
| Ndb_api_bytes_received_count | 86940 |
| Ndb_api_trans_start_count | 308 |
| Ndb_api_trans_commit_count | 308 |
| Ndb_api_trans_abort_count | 0 |
| Ndb_api_trans_close_count | 308 |
| Ndb_api_pk_op_count | 311 |
| Ndb_api_uk_op_count | 0 |
| Ndb_api_table_scan_count | 0 |
| Ndb_api_range_scan_count | 0 |
| Ndb_api_pruned_scan_count | 0 |
| Ndb_api_scan_batch_count | 0 |
| Ndb_api_read_row_count | 307 |
| Ndb_api_trans_local_read_row_count | 77 |
| Ndb_api_adaptive_send_forced_count | 3 |
| Ndb_api_adaptive_send_unforced_count | 614 |
| Ndb_api_adaptive_send_deferred_count | 0 |
| Ndb_api_event_data_count | 0 |
| Ndb_api_event_nondata_count | 0 |
| Ndb_api_event_bytes_count | 0 |
| Ndb_api_wait_exec_complete_count_slave | 0 |
| Ndb_api_wait_scan_result_count_slave | 0 |
| Ndb_api_wait_meta_request_count_slave | 0 |
| Ndb_api_wait_nanos_count_slave | 0 |
| Ndb_api_bytes_sent_count_slave | 0 |
| Ndb_api_bytes_received_count_slave | 0 |
| Ndb_api_trans_start_count_slave | 0 |
| Ndb_api_trans_commit_count_slave | 0 |
| Ndb_api_trans_abort_count_slave | 0 |
| Ndb_api_trans_close_count_slave | 0 |
| Ndb_api_pk_op_count_slave | 0 |
| Ndb_api_uk_op_count_slave | 0 |
| Ndb_api_table_scan_count_slave | 0 |
| Ndb_api_range_scan_count_slave | 0 |
| Ndb_api_pruned_scan_count_slave | 0 |
| Ndb_api_scan_batch_count_slave | 0 |
| Ndb_api_read_row_count_slave | 0 |
| Ndb_api_trans_local_read_row_count_slave | 0 |
| Ndb_api_adaptive_send_forced_count_slave | 0 |
| Ndb_api_adaptive_send_unforced_count_slave | 0 |
| Ndb_api_adaptive_send_deferred_count_slave | 0 |
| Ndb_api_wait_exec_complete_count_replica | 0 |
| Ndb_api_wait_scan_result_count_replica | 0 |
| Ndb_api_wait_meta_request_count_replica | 0 |
| Ndb_api_wait_nanos_count_replica | 0 |
| Ndb_api_bytes_sent_count_replica | 0 |
| Ndb_api_bytes_received_count_replica | 0 |
| Ndb_api_trans_start_count_replica | 0 |
| Ndb_api_trans_commit_count_replica | 0 |
| Ndb_api_trans_abort_count_replica | 0 |
| Ndb_api_trans_close_count_replica | 0 |
| Ndb_api_pk_op_count_replica | 0 |
| Ndb_api_uk_op_count_replica | 0 |
| Ndb_api_table_scan_count_replica | 0 |
| Ndb_api_range_scan_count_replica | 0 |
| Ndb_api_pruned_scan_count_replica | 0 |
| Ndb_api_scan_batch_count_replica | 0 |
| Ndb_api_read_row_count_replica | 0 |
| Ndb_api_trans_local_read_row_count_replica | 0 |
| Ndb_api_adaptive_send_forced_count_replica | 0 |
| Ndb_api_adaptive_send_unforced_count_replica | 0 |
| Ndb_api_adaptive_send_deferred_count_replica | 0 |
| Ndb_api_event_data_count_injector | 0 |
| Ndb_api_event_nondata_count_injector | 0 |
| Ndb_api_event_bytes_count_injector | 0 |
| Ndb_api_wait_exec_complete_count_session | 0 |
| Ndb_api_wait_scan_result_count_session | 0 |
| Ndb_api_wait_meta_request_count_session | 0 |
| Ndb_api_wait_nanos_count_session | 0 |
| Ndb_api_bytes_sent_count_session | 0 |
| Ndb_api_bytes_received_count_session | 0 |
| Ndb_api_trans_start_count_session | 0 |
| Ndb_api_trans_commit_count_session | 0 |
| Ndb_api_trans_abort_count_session | 0 |
| Ndb_api_trans_close_count_session | 0 |
| Ndb_api_pk_op_count_session | 0 |
| Ndb_api_uk_op_count_session | 0 |
| Ndb_api_table_scan_count_session | 0 |
| Ndb_api_range_scan_count_session | 0 |
| Ndb_api_pruned_scan_count_session | 0 |
| Ndb_api_scan_batch_count_session | 0 |
| Ndb_api_read_row_count_session | 0 |
| Ndb_api_trans_local_read_row_count_session | 0 |
| Ndb_api_adaptive_send_forced_count_session | 0 |
| Ndb_api_adaptive_send_unforced_count_session | 0 |
| Ndb_api_adaptive_send_deferred_count_session | 0 |
+———————————————-+—————-+
90 rows in set (0.01 sec)
mysql> SELECT * FROM performance_schema.global_status
-> WHERE VARIABLE_NAME LIKE \’ndb_api%\’;
+———————————————-+—————-+
| VARIABLE_NAME | VARIABLE_VALUE |
+———————————————-+—————-+
| Ndb_api_wait_exec_complete_count | 741 |
| Ndb_api_wait_scan_result_count | 0 |
| Ndb_api_wait_meta_request_count | 777 |
| Ndb_api_wait_nanos_count | 373888309 |
| Ndb_api_bytes_sent_count | 78124 |
| Ndb_api_bytes_received_count | 94988 |
| Ndb_api_trans_start_count | 370 |
| Ndb_api_trans_commit_count | 370 |
| Ndb_api_trans_abort_count | 0 |
| Ndb_api_trans_close_count | 370 |
| Ndb_api_pk_op_count | 373 |
| Ndb_api_uk_op_count | 0 |
| Ndb_api_table_scan_count | 0 |
| Ndb_api_range_scan_count | 0 |
| Ndb_api_pruned_scan_count | 0 |
| Ndb_api_scan_batch_count | 0 |
| Ndb_api_read_row_count | 369 |
| Ndb_api_trans_local_read_row_count | 93 |
| Ndb_api_adaptive_send_forced_count | 3 |
| Ndb_api_adaptive_send_unforced_count | 738 |
| Ndb_api_adaptive_send_deferred_count | 0 |
| Ndb_api_event_data_count | 0 |
| Ndb_api_event_nondata_count | 0 |
| Ndb_api_event_bytes_count | 0 |
| Ndb_api_wait_exec_complete_count_slave | 0 |
| Ndb_api_wait_scan_result_count_slave | 0 |
| Ndb_api_wait_meta_request_count_slave | 0 |
| Ndb_api_wait_nanos_count_slave | 0 |
| Ndb_api_bytes_sent_count_slave | 0 |
| Ndb_api_bytes_received_count_slave | 0 |
| Ndb_api_trans_start_count_slave | 0 |
| Ndb_api_trans_commit_count_slave | 0 |
| Ndb_api_trans_abort_count_slave | 0 |
| Ndb_api_trans_close_count_slave | 0 |
| Ndb_api_pk_op_count_slave | 0 |
| Ndb_api_uk_op_count_slave | 0 |
| Ndb_api_table_scan_count_slave | 0 |
| Ndb_api_range_scan_count_slave | 0 |
| Ndb_api_pruned_scan_count_slave | 0 |
| Ndb_api_scan_batch_count_slave | 0 |
| Ndb_api_read_row_count_slave | 0 |
| Ndb_api_trans_local_read_row_count_slave | 0 |
| Ndb_api_adaptive_send_forced_count_slave | 0 |
| Ndb_api_adaptive_send_unforced_count_slave | 0 |
| Ndb_api_adaptive_send_deferred_count_slave | 0 |
| Ndb_api_wait_exec_complete_count_replica | 0 |
| Ndb_api_wait_scan_result_count_replica | 0 |
| Ndb_api_wait_meta_request_count_replica | 0 |
| Ndb_api_wait_nanos_count_replica | 0 |
| Ndb_api_bytes_sent_count_replica | 0 |
| Ndb_api_bytes_received_count_replica | 0 |
| Ndb_api_trans_start_count_replica | 0 |
| Ndb_api_trans_commit_count_replica | 0 |
| Ndb_api_trans_abort_count_replica | 0 |
| Ndb_api_trans_close_count_replica | 0 |
| Ndb_api_pk_op_count_replica | 0 |
| Ndb_api_uk_op_count_replica | 0 |
| Ndb_api_table_scan_count_replica | 0 |
| Ndb_api_range_scan_count_replica | 0 |
| Ndb_api_pruned_scan_count_replica | 0 |
| Ndb_api_scan_batch_count_replica | 0 |
| Ndb_api_read_row_count_replica | 0 |
| Ndb_api_trans_local_read_row_count_replica | 0 |
| Ndb_api_adaptive_send_forced_count_replica | 0 |
| Ndb_api_adaptive_send_unforced_count_replica | 0 |
| Ndb_api_adaptive_send_deferred_count_replica | 0 |
| Ndb_api_event_data_count_injector | 0 |
| Ndb_api_event_nondata_count_injector | 0 |
| Ndb_api_event_bytes_count_injector | 0 |
| Ndb_api_wait_exec_complete_count_session | 0 |
| Ndb_api_wait_scan_result_count_session | 0 |
| Ndb_api_wait_meta_request_count_session | 0 |
| Ndb_api_wait_nanos_count_session | 0 |
| Ndb_api_bytes_sent_count_session | 0 |
| Ndb_api_bytes_received_count_session | 0 |
| Ndb_api_trans_start_count_session | 0 |
| Ndb_api_trans_commit_count_session | 0 |
| Ndb_api_trans_abort_count_session | 0 |
| Ndb_api_trans_close_count_session | 0 |
| Ndb_api_pk_op_count_session | 0 |
| Ndb_api_uk_op_count_session | 0 |
| Ndb_api_table_scan_count_session | 0 |
| Ndb_api_range_scan_count_session | 0 |
| Ndb_api_pruned_scan_count_session | 0 |
| Ndb_api_scan_batch_count_session | 0 |
| Ndb_api_read_row_count_session | 0 |
| Ndb_api_trans_local_read_row_count_session | 0 |
| Ndb_api_adaptive_send_forced_count_session | 0 |
| Ndb_api_adaptive_send_unforced_count_session | 0 |
| Ndb_api_adaptive_send_deferred_count_session | 0 |
+———————————————-+—————-+
90 rows in set (0.01 sec)

每个Ndb对象都有自己的计数器。NDB API 应用程序可以读取这些计数器的值，用于优化或监控。对于同时使用多个Ndb对象的多线程客户端，还可以从属于给定Ndb_cluster_connection的所有Ndb对象获取计数器的总和视图。

有四组这些计数器可供查看。一组适用于当前会话；另外 3 组是全局的。尽管它们的值可以作为mysql客户端的会话或全局状态变量获得。这意味着在SHOW STATUS中指定SESSION或GLOBAL关键字对 NDB API 统计状态变量报告的值没有影响，每个变量的值无论是从session_status表的等效列还是从global_status表获得，其值都是相同的。

会话计数器（特定会话）
会话计数器与当前会话中使用的Ndb对象相关。其他 MySQL 客户端对这些对象的使用不会影响这些计数。
为了最大限度地减少与标准 MySQL 会话变量的混淆，我们将与这些 NDB API 会话计数器对应的变量称为“_session变量”，带有前导下划线。
复制计数器（全局）
这组计数器与复制 SQL 线程（如果有）使用的Ndb对象相关。如果此mysqld不充当复制品，或不使用NDB表，则所有这些计数都为 0。
我们将相关的状态变量称为“_slave变量”（带有前导下划线）。
注入器计数器（全局）
注入器计数器与二进制日志注入器线程监听集群事件所使用的Ndb对象相关。即使不写入二进制日志，附加到 NDB 集群的mysqld进程仍会继续监听某些事件，如模式更改。
我们将与 NDB API 注入器计数器对应的状态变量称为“_injector变量”（带有前导下划线）。
服务器（全局）计数器（全局）
这组计数器与当前mysqld使用的所有Ndb对象相关。这包括所有 MySQL 客户端应用程序、复制 SQL 线程（如果有）、二进制日志注入器和NDB实用程序线程。
我们将与这些计数器对应的状态变量称为“全局变量”或“mysqld级别变量”。

你可以通过在变量名中额外过滤子字符串 session、slave 或 injector（以及共同前缀 Ndb_api）来获取特定一组变量的值。对于 _session 变量，可以按照这里所示进行操作：

mysql> SHOW STATUS LIKE \’ndb_api%session\’;
+——————————————–+———+
| Variable_name | Value |
+——————————————–+———+
| Ndb_api_wait_exec_complete_count_session | 2 |
| Ndb_api_wait_scan_result_count_session | 0 |
| Ndb_api_wait_meta_request_count_session | 1 |
| Ndb_api_wait_nanos_count_session | 8144375 |
| Ndb_api_bytes_sent_count_session | 68 |
| Ndb_api_bytes_received_count_session | 84 |
| Ndb_api_trans_start_count_session | 1 |
| Ndb_api_trans_commit_count_session | 1 |
| Ndb_api_trans_abort_count_session | 0 |
| Ndb_api_trans_close_count_session | 1 |
| Ndb_api_pk_op_count_session | 1 |
| Ndb_api_uk_op_count_session | 0 |
| Ndb_api_table_scan_count_session | 0 |
| Ndb_api_range_scan_count_session | 0 |
| Ndb_api_pruned_scan_count_session | 0 |
| Ndb_api_scan_batch_count_session | 0 |
| Ndb_api_read_row_count_session | 1 |
| Ndb_api_trans_local_read_row_count_session | 1 |
+——————————————–+———+
18 rows in set (0.50 sec)

要获取 NDB API mysqld 级别状态变量的列表，请过滤以 ndb_api 开头且以 _count 结尾的变量名，就像这样：

mysql> SELECT * FROM performance_schema.session_status
-> WHERE VARIABLE_NAME LIKE \’ndb_api%count\’;
+————————————+—————-+
| VARIABLE_NAME | VARIABLE_VALUE |
+————————————+—————-+
| NDB_API_WAIT_EXEC_COMPLETE_COUNT | 4 |
| NDB_API_WAIT_SCAN_RESULT_COUNT | 3 |
| NDB_API_WAIT_META_REQUEST_COUNT | 28 |
| NDB_API_WAIT_NANOS_COUNT | 53756398 |
| NDB_API_BYTES_SENT_COUNT | 1060 |
| NDB_API_BYTES_RECEIVED_COUNT | 9724 |
| NDB_API_TRANS_START_COUNT | 3 |
| NDB_API_TRANS_COMMIT_COUNT | 2 |
| NDB_API_TRANS_ABORT_COUNT | 0 |
| NDB_API_TRANS_CLOSE_COUNT | 3 |
| NDB_API_PK_OP_COUNT | 2 |
| NDB_API_UK_OP_COUNT | 0 |
| NDB_API_TABLE_SCAN_COUNT | 1 |
| NDB_API_RANGE_SCAN_COUNT | 0 |
| NDB_API_PRUNED_SCAN_COUNT | 0 |
| NDB_API_SCAN_BATCH_COUNT | 0 |
| NDB_API_READ_ROW_COUNT | 2 |
| NDB_API_TRANS_LOCAL_READ_ROW_COUNT | 2 |
| NDB_API_EVENT_DATA_COUNT | 0 |
| NDB_API_EVENT_NONDATA_COUNT | 0 |
| NDB_API_EVENT_BYTES_COUNT | 0 |
+————————————+—————-+
21 rows in set (0.09 sec)

并非所有计数器都反映在所有 4 组状态变量中。对于事件计数器 DataEventsRecvdCount、NondataEventsRecvdCount 和 EventBytesRecvdCount，仅有 _injector 和 mysqld 级别的 NDB API 状态变量可用：

mysql> SHOW STATUS LIKE \’ndb_api%event%\’;
+————————————–+——-+
| Variable_name | Value |
+————————————–+——-+
| Ndb_api_event_data_count_injector | 0 |
| Ndb_api_event_nondata_count_injector | 0 |
| Ndb_api_event_bytes_count_injector | 0 |
| Ndb_api_event_data_count | 0 |
| Ndb_api_event_nondata_count | 0 |
| Ndb_api_event_bytes_count | 0 |
+————————————–+——-+
6 rows in set (0.00 sec)

对于任何其他 NDB API 计数器，都未实现 _injector 状态变量，如下所示：

状态变量的名称可以轻松与相应计数器的名称关联起来。每个 NDB API 统计计数器在以下表中列出，包括描述以及与该计数器对应的任何 MySQL 服务器状态变量的名称。

表 25.67 NDB API 统计计数器

| 计数器名称 | 描述 | 状态变量（按统计类型）：

会话
从库（副本）
注入器
服务器

WaitExecCompleteCount线程在等待操作完成时被阻塞的次数。包括所有 execute() 调用，以及对 blob 操作和对客户端不可见的自增操作的隐式执行。
Ndb_api_wait_exec_complete_count_session
Ndb_api_wait_exec_complete_count_slave
[无]
Ndb_api_wait_exec_complete_count

WaitScanResultCount线程在等待扫描信号时被阻塞的次数，例如等待额外结果或等待扫描关闭。
Ndb_api_wait_scan_result_count_session
Ndb_api_wait_scan_result_count_slave
[无]
Ndb_api_wait_scan_result_count

WaitMetaRequestCount线程被阻塞等待基于元数据的信号的次数；当等待 DDL 操作或等待开始（或结束）时代时，可能会发生这种情况。
Ndb_api_wait_meta_request_count_session
Ndb_api_wait_meta_request_count_slave
[无]
Ndb_api_wait_meta_request_count

WaitNanosCount从数据节点等待某种信号所花费的总时间（以纳秒为单位）。
Ndb_api_wait_nanos_count_session
Ndb_api_wait_nanos_count_slave
[none]
Ndb_api_wait_nanos_count

BytesSentCount发送到数据节点的数据量（以字节为单位）。
Ndb_api_bytes_sent_count_session
Ndb_api_bytes_sent_count_slave
[none]
Ndb_api_bytes_sent_count

BytesRecvdCount从数据节点接收的数据量（以字节为单位）。
Ndb_api_bytes_received_count_session
Ndb_api_bytes_received_count_slave
[none]
Ndb_api_bytes_received_count

TransStartCount开始的事务数。
Ndb_api_trans_start_count_session
Ndb_api_trans_start_count_slave
[none]
Ndb_api_trans_start_count

TransCommitCount提交的事务数。
Ndb_api_trans_commit_count_session
Ndb_api_trans_commit_count_slave
[none]
Ndb_api_trans_commit_count

TransAbortCount中止的事务数。
Ndb_api_trans_abort_count_session
Ndb_api_trans_abort_count_slave
[none]
Ndb_api_trans_abort_count

TransCloseCount中止的事务数。（此值可能大于TransCommitCount和TransAbortCount的总和。）
Ndb_api_trans_close_count_session
Ndb_api_trans_close_count_slave
[none]
Ndb_api_trans_close_count

PkOpCount基于或使用主键的操作次数。此计数包括 blob-part 表操作、隐式解锁操作和自增操作，以及通常对 MySQL 客户端可见的主键操作。
Ndb_api_pk_op_count_session
Ndb_api_pk_op_count_slave
[无]
Ndb_api_pk_op_count

UkOpCount基于或使用唯一键的操作次数。
Ndb_api_uk_op_count_session
Ndb_api_uk_op_count_slave
[无]
Ndb_api_uk_op_count

TableScanCount已启动的表扫描次数。这包括对内部表的扫描。
Ndb_api_table_scan_count_session
Ndb_api_table_scan_count_slave
[无]
Ndb_api_table_scan_count

RangeScanCount已启动的范围扫描次数。
Ndb_api_range_scan_count_session
Ndb_api_range_scan_count_slave
[无]
Ndb_api_range_scan_count

PrunedScanCount已被剪枝为单个分区的扫描次数。
Ndb_api_pruned_scan_count_session
Ndb_api_pruned_scan_count_slave
[无]
Ndb_api_pruned_scan_count

ScanBatchCount接收的行批次数。（在此上下文中，批次是来自单个片段的扫描结果集。）
Ndb_api_scan_batch_count_session
Ndb_api_scan_batch_count_slave
[无]
Ndb_api_scan_batch_count

ReadRowCount已读取的总行数。包括使用主键、唯一键和扫描操作读取的行。
Ndb_api_read_row_count_session
Ndb_api_read_row_count_slave
[无]
Ndb_api_read_row_count

TransLocalReadRowCount从运行事务的同一节点上读取的行数。
Ndb_api_trans_local_read_row_count_session
Ndb_api_trans_local_read_row_count_slave
[无]
Ndb_api_trans_local_read_row_count

DataEventsRecvdCount接收的行更改事件数。
[无]
[无]
Ndb_api_event_data_count_injector
Ndb_api_event_data_count

NondataEventsRecvdCount接收的事件数，除了行更改事件。
[无]
[无]
Ndb_api_event_nondata_count_injector
Ndb_api_event_nondata_count

EventBytesRecvdCount接收的事件字节数。
[无]
[无]
Ndb_api_event_bytes_count_injector
Ndb_api_event_bytes_count

| 计数器名称 | 描述 | 状态变量（按统计类型）：

会话
从属（副本）
注入器
服务器

要查看所有已提交事务的计数，即所有TransCommitCount计数器状态变量，您可以将SHOW STATUS的结果过滤为子字符串trans_commit_count，就像这样：

从中您可以确定当前mysql客户端会话中已提交了 1 个事务，并且自上次重新启动以来，此mysqld上已提交了 2 个事务。

您可以通过比较执行语句前后相应_session状态变量的值来查看给定 SQL 语句如何递增各种 NDB API 计数器。在此示例中，在从SHOW STATUS获取初始值后，我们在test数据库中创建一个名为t的NDB表，该表只有一列：

mysql> SHOW STATUS LIKE \’ndb_api%session%\’;
+——————————————–+——–+
| Variable_name | Value |
+——————————————–+——–+
| Ndb_api_wait_exec_complete_count_session | 2 |
| Ndb_api_wait_scan_result_count_session | 0 |
| Ndb_api_wait_meta_request_count_session | 3 |
| Ndb_api_wait_nanos_count_session | 820705 |
| Ndb_api_bytes_sent_count_session | 132 |
| Ndb_api_bytes_received_count_session | 372 |
| Ndb_api_trans_start_count_session | 1 |
| Ndb_api_trans_commit_count_session | 1 |
| Ndb_api_trans_abort_count_session | 0 |
| Ndb_api_trans_close_count_session | 1 |
| Ndb_api_pk_op_count_session | 1 |
| Ndb_api_uk_op_count_session | 0 |
| Ndb_api_table_scan_count_session | 0 |
| Ndb_api_range_scan_count_session | 0 |
| Ndb_api_pruned_scan_count_session | 0 |
| Ndb_api_scan_batch_count_session | 0 |
| Ndb_api_read_row_count_session | 1 |
| Ndb_api_trans_local_read_row_count_session | 1 |
+——————————————–+——–+
18 rows in set (0.00 sec)
mysql> USE test;
Database changed
mysql> CREATE TABLE t (c INT) ENGINE NDBCLUSTER;
Query OK, 0 rows affected (0.85 sec)

现在，您可以执行一个新的SHOW STATUS语句并观察更改，如下所示（在输出中突出显示更改的行）：

mysql> SHOW STATUS LIKE \’ndb_api%session%\’;
+——————————————–+———–+
| Variable_name | Value |
+——————————————–+———–+ *| Ndb_api_wait_exec_complete_count_session | 8 |* | Ndb_api_wait_scan_result_count_session | 0 |
*| Ndb_api_wait_meta_request_count_session | 17 |*
*| Ndb_api_wait_nanos_count_session | 706871709 |*
*| Ndb_api_bytes_sent_count_session | 2376 |*
*| Ndb_api_bytes_received_count_session | 3844 |*
*| Ndb_api_trans_start_count_session | 4 |*
*| Ndb_api_trans_commit_count_session | 4 |*
| Ndb_api_trans_abort_count_session | 0 |
*| Ndb_api_trans_close_count_session | 4 |*
*| Ndb_api_pk_op_count_session | 6 |*
| Ndb_api_uk_op_count_session | 0 |
| Ndb_api_table_scan_count_session | 0 |
| Ndb_api_range_scan_count_session | 0 |
| Ndb_api_pruned_scan_count_session | 0 |
| Ndb_api_scan_batch_count_session | 0 |
*| Ndb_api_read_row_count_session | 2 |*
| Ndb_api_trans_local_read_row_count_session | 1 |
+——————————————–+———–+
18 rows in set (0.00 sec)

同样，您可以看到通过向t插入一行导致的 NDB API 统计计数器的变化：插入行，然后运行与前一个示例中使用的相同的SHOW STATUS语句，如下所示：

mysql> INSERT INTO t VALUES (100);
Query OK, 1 row affected (0.00 sec)
mysql> SHOW STATUS LIKE \’ndb_api%session%\’;
+——————————————–+———–+
| Variable_name | Value |
+——————————————–+———–+
*| Ndb_api_wait_exec_complete_count_session | 11 |*
*| Ndb_api_wait_scan_result_count_session | 6 |*
*| Ndb_api_wait_meta_request_count_session | 20 |*
*| Ndb_api_wait_nanos_count_session | 707370418 |*
*| Ndb_api_bytes_sent_count_session | 2724 |*
*| Ndb_api_bytes_received_count_session | 4116 |*
*| Ndb_api_trans_start_count_session | 7 |*
*| Ndb_api_trans_commit_count_session | 6 |*
| Ndb_api_trans_abort_count_session | 0 |
*| Ndb_api_trans_close_count_session | 7 |*
*| Ndb_api_pk_op_count_session | 8 |*
| Ndb_api_uk_op_count_session | 0 |
*| Ndb_api_table_scan_count_session | 1 |*
| Ndb_api_range_scan_count_session | 0 |
| Ndb_api_pruned_scan_count_session | 0 |
| Ndb_api_scan_batch_count_session | 0 |
*| Ndb_api_read_row_count_session | 3 |*
*| Ndb_api_trans_local_read_row_count_session | 2 |*
+——————————————–+———–+
18 rows in set (0.00 sec)

我们可以从这些结果中得出许多观察结果：

虽然我们创建了t，没有明确的主键，但在此过程中执行了 5 次主键操作（Ndb_api_pk_op_count_session的“之前”和“之后”值的差异，或者 6 减 1）。这反映了隐藏主键的创建，这是所有使用NDB存储引擎的表的特点。
通过比较Ndb_api_wait_nanos_count_session的连续值，我们可以看到实现CREATE TABLE语句的 NDB API 操作等待的时间要长得多（706871709 – 820705 = 706051004 纳秒，或大约 0.7 秒），以获取来自数据节点的响应，比执行INSERT的操作（707370418 – 706871709 = 498709 ns，或大约 0.0005 秒）要长。在mysql客户端中报告的执行时间与这些数字大致相关。
在没有足够（纳秒）时间分辨率的平台上，由于执行非常快的 SQL 语句而导致WaitNanosCount NDB API 计数器值的微小变化，可能不总是在Ndb_api_wait_nanos_count_session、Ndb_api_wait_nanos_count_slave或Ndb_api_wait_nanos_count的值中可见。
INSERT语句增加了ReadRowCount和TransLocalReadRowCount NDB API 统计计数器，反映在Ndb_api_read_row_count_session和Ndb_api_trans_local_read_row_count_session的增加值。

25.6.16 ndbinfo: NDB 集群信息数据库

原文：dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo.html

25.6.16.1 ndbinfo arbitrator_validity_detail 表

25.6.16.2 ndbinfo arbitrator_validity_summary 表

25.6.16.3 ndbinfo backup_id 表

25.6.16.4 ndbinfo blobs 表

25.6.16.5 ndbinfo blocks 表

25.6.16.6 ndbinfo cluster_locks 表

25.6.16.7 ndbinfo cluster_operations 表

25.6.16.8 ndbinfo cluster_transactions 表

25.6.16.9 ndbinfo config_nodes 表

25.6.16.10 ndbinfo config_params 表

25.6.16.11 ndbinfo config_values 表

25.6.16.12 ndbinfo counters 表

25.6.16.13 ndbinfo cpudata 表

25.6.16.14 ndbinfo cpudata_1sec 表

25.6.16.15 ndbinfo cpudata_20sec 表

25.6.16.16 ndbinfo cpudata_50ms 表

25.6.16.17 ndbinfo cpuinfo 表

25.6.16.18 ndbinfo cpustat 表

25.6.16.19 ndbinfo cpustat_50ms 表

25.6.16.20 ndbinfo cpustat_1sec 表

25.6.16.21 ndbinfo cpustat_20sec 表

25.6.16.22 ndbinfo dictionary_columns 表

25.6.16.23 ndbinfo dictionary_tables 表

25.6.16.24 ndbinfo dict_obj_info 表

25.6.16.25 ndbinfo dict_obj_tree 表

25.6.16.26 ndbinfo dict_obj_types 表

25.6.16.27 ndbinfo disk_write_speed_base 表

25.6.16.28 ndbinfo disk_write_speed_aggregate 表

25.6.16.29 ndbinfo disk_write_speed_aggregate_node 表

25.6.16.30 ndbinfo diskpagebuffer 表

25.6.16.31 ndbinfo diskstat 表

25.6.16.32 ndbinfo diskstats_1sec 表

25.6.16.33 ndbinfo error_messages 表

25.6.16.34 ndbinfo events 表

25.6.16.35 ndbinfo files 表

25.6.16.36 ndbinfo foreign_keys 表

25.6.16.37 ndbinfo hash_maps 表

25.6.16.38 ndbinfo hwinfo 表

25.6.16.39 ndbinfo index_columns 表

25.6.16.40 ndbinfo index_stats 表

25.6.16.41 ndbinfo locks_per_fragment 表

25.6.16.42 ndbinfo logbuffers 表

25.6.16.43 ndbinfo logspaces 表

25.6.16.44 ndbinfo membership 表

25.6.16.45 ndbinfo memoryusage 表

25.6.16.46 ndbinfo memory_per_fragment 表

25.6.16.47 ndbinfo nodes 表

25.6.16.48 ndbinfo operations_per_fragment 表

25.6.16.49 ndbinfo pgman_time_track_stats 表

25.6.16.50 ndbinfo processes 表

25.6.16.51 ndbinfo resources 表

25.6.16.52 ndbinfo restart_info 表

25.6.16.53 ndbinfo server_locks 表

25.6.16.54 ndbinfo server_operations 表

25.6.16.55 ndbinfo server_transactions 表

25.6.16.56 ndbinfo table_distribution_status 表

25.6.16.57 ndbinfo table_fragments 表

25.6.16.58 ndbinfo table_info 表

25.6.16.59 ndbinfo table_replicas 表

25.6.16.60 ndbinfo tc_time_track_stats 表

25.6.16.61 ndbinfo threadblocks 表

25.6.16.62 ndbinfo threads 表

25.6.16.63 ndbinfo threadstat 表

25.6.16.64 ndbinfo transporter_details 表

25.6.16.65 ndbinfo transporters 表

ndbinfo是一个包含特定于 NDB Cluster 的信息的数据库。

该数据库包含许多表，每个表提供关于 NDB Cluster 节点状态、资源使用情况和操作的不同类型数据。您可以在接下来的几节中找到关于每个表的更详细信息。

ndbinfo包含在 MySQL Server 中的 NDB Cluster 支持中；不需要特殊的编译或配置步骤；当 MySQL Server 连接到集群时，这些表由 MySQL Server 创建。您可以使用SHOW PLUGINS验证给定 MySQL Server 实例中是否激活了ndbinfo支持；如果启用了ndbinfo支持，您应该看到Name列中包含ndbinfo，Status列中包含ACTIVE的行，如下所示（强调文本）：

您还可以通过检查SHOW ENGINES的输出，查看包含ndbinfo的行以及Support列中的YES，如下所示（强调文本）：

mysql> SHOW ENGINES\\G
*************************** 1\\. row ***************************
Engine: ndbcluster
Support: YES
Comment: Clustered, fault-tolerant tables
Transactions: YES
XA: NO
Savepoints: NO
*************************** 2\\. row ***************************
Engine: CSV
Support: YES
Comment: CSV storage engine
Transactions: NO
XA: NO
Savepoints: NO
*************************** 3\\. row ***************************
Engine: InnoDB
Support: DEFAULT
Comment: Supports transactions, row-level locking, and foreign keys
Transactions: YES
XA: YES
Savepoints: YES
*************************** 4\\. row ***************************
Engine: BLACKHOLE
Support: YES
Comment: /dev/null storage engine (anything you write to it disappears)
Transactions: NO
XA: NO
Savepoints: NO
*************************** 5\\. row ***************************
Engine: MyISAM
Support: YES
Comment: MyISAM storage engine
Transactions: NO
XA: NO
Savepoints: NO
*************************** 6\\. row ***************************
Engine: MRG_MYISAM
Support: YES
Comment: Collection of identical MyISAM tables
Transactions: NO
XA: NO
Savepoints: NO
*************************** 7\\. row ***************************
Engine: ARCHIVE
Support: YES
Comment: Archive storage engine
Transactions: NO
XA: NO
Savepoints: NO
**************************** 8\\. row ***************************
Engine: ndbinfo
Support: YES
Comment: NDB Cluster system information storage engine
Transactions: NO
XA: NO
Savepoints: NO*
*************************** 9\\. row ***************************
Engine: PERFORMANCE_SCHEMA
Support: YES
Comment: Performance Schema
Transactions: NO
XA: NO
Savepoints: NO
*************************** 10\\. row ***************************
Engine: MEMORY
Support: YES
Comment: Hash based, stored in memory, useful for temporary tables
Transactions: NO
XA: NO
Savepoints: NO 10 rows in set (0.00 sec)

如果启用了ndbinfo支持，则可以使用 SQL 语句在mysql或其他 MySQL 客户端中访问ndbinfo。例如，您可以在SHOW DATABASES的输出中看到ndbinfo，如下所示（强调文本）：

如果mysqld进程未使用–ndbcluster选项启动，则ndbinfo不可用，并且不会显示在SHOW DATABASES中。如果mysqld曾连接到 NDB Cluster 但集群不可用（由于事件如集群关闭、网络连接丢失等），ndbinfo及其表仍然可见，但尝试访问任何表（除了blocks或config_params）将失败，并显示错误 157 ‘Connection to NDB failed’ from NDBINFO。

除了blocks和config_params表之外，我们所说的ndbinfo“表”实际上是从内部NDB表生成的视图，通常对 MySQL Server 不可见。您可以通过将ndbinfo_show_hidden系统变量设置为ON（或1）来使这些表可见，但通常不需要这样做。

所有 ndbinfo 表都是只读的，并在查询时按需生成。因为许多表是由数据节点并行生成的，而其他表是特定于给定的 SQL 节点，所以不能保证提供一致的快照。

此外，在 ndbinfo 表上不支持连接的下推；因此，连接大型 ndbinfo 表可能需要将大量数据传输到请求的 API 节点，即使查询使用 WHERE 子句。

ndbinfo 表不包含在查询缓存中。（Bug #59831）

你可以使用 USE 语句选择 ndbinfo 数据库，然后发出 SHOW TABLES 语句获取表的列表，就像对待任何其他数据库一样，如下所示：

在 NDB 8.0 中，所有 ndbinfo 表都使用 NDB 存储引擎；然而，在SHOW ENGINES和SHOW PLUGINS的输出中仍会出现一个 ndbinfo 条目，如前所述。

你可以执行对这些表的SELECT语句，就像你通常期望的那样：

mysql> SELECT * FROM memoryusage;
+———+———————+——–+————+————+————-+
| node_id | memory_type | used | used_pages | total | total_pages |
+———+———————+——–+————+————+————-+
| 5 | Data memory | 425984 | 13 | 2147483648 | 65536 |
| 5 | Long message buffer | 393216 | 1536 | 67108864 | 262144 |
| 6 | Data memory | 425984 | 13 | 2147483648 | 65536 |
| 6 | Long message buffer | 393216 | 1536 | 67108864 | 262144 |
| 7 | Data memory | 425984 | 13 | 2147483648 | 65536 |
| 7 | Long message buffer | 393216 | 1536 | 67108864 | 262144 |
| 8 | Data memory | 425984 | 13 | 2147483648 | 65536 |
| 8 | Long message buffer | 393216 | 1536 | 67108864 | 262144 |
+———+———————+——–+————+————+————-+
8 rows in set (0.09 sec)

更复杂的查询，比如以下两个使用memoryusage表的SELECT语句，是可能的：

mysql> SELECT SUM(used) as \’Data Memory Used, All Nodes\’
> FROM memoryusage
> WHERE memory_type = \’Data memory\’;
+—————————–+
| Data Memory Used, All Nodes |
+—————————–+
| 6460 |
+—————————–+
1 row in set (0.09 sec)
mysql> SELECT SUM(used) as \’Long Message Buffer, All Nodes\’
> FROM memoryusage
> WHERE memory_type = \’Long message buffer\’;
+————————————-+
| Long Message Buffer Used, All Nodes |
+————————————-+
| 1179648 |
+————————————-+
1 row in set (0.08 sec)

ndbinfo 表和列名区分大小写（ndbinfo 数据库本身的名称也是如此）。这些标识符是小写的。尝试使用错误的大小写会导致错误，如下例所示：

mysql> SELECT * FROM nodes;
+———+——–+———+————-+——————-+
| node_id | uptime | status | start_phase | config_generation |
+———+——–+———+————-+——————-+
| 5 | 17707 | STARTED | 0 | 1 |
| 6 | 17706 | STARTED | 0 | 1 |
| 7 | 17705 | STARTED | 0 | 1 |
| 8 | 17704 | STARTED | 0 | 1 |
+———+——–+———+————-+——————-+
4 rows in set (0.06 sec)
mysql> SELECT * FROM Nodes;
ERROR 1146 (42S02): Table \’ndbinfo.Nodes\’ doesn\’t exist

mysqldump 完全忽略 ndbinfo 数据库，并将其从任何输出中排除。即使使用 –databases 或 –all-databases 选项也是如此。

NDB Cluster 还在 INFORMATION_SCHEMA 信息数据库中维护表，包括包含有关用于 NDB Cluster 磁盘数据存储的文件的信息的FILES表，以及显示事务、事务协调器和 NDB Cluster API 节点之间关系的ndb_transid_mysql_connection_map表。有关更多信息，请参阅表的描述或第 25.6.17 节，“NDB Cluster 的 INFORMATION_SCHEMA 表”。

原文：dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-arbitrator-validity-detail.html

25.6.16.1 ndbinfo arbitrator_validity_detail 表

arbitrator_validity_detail 表显示集群中每个数据节点对仲裁者的视图。它是membership表的子集。

arbitrator_validity_detail 表包含以下列：

node_id
此节点的节点 ID
仲裁者
仲裁者的节点 ID
arb_ticket
用于跟踪仲裁的内部标识符
arb_connected
此节点是否连接到仲裁者；是Yes或No中的一个
arb_state
仲裁状态

备注

节点 ID 与**ndb_mgm -e “SHOW”**报告的相同。

所有节点应该显示相同的仲裁者和arb_ticket值，以及相同的arb_state值。可能的arb_state值包括ARBIT_NULL、ARBIT_INIT、ARBIT_FIND、ARBIT_PREP1、ARBIT_PREP2、ARBIT_START、ARBIT_RUN、ARBIT_CHOOSE、ARBIT_CRASH和UNKNOWN。

arb_connected 显示当前节点是否连接到仲裁者。

原文：dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-arbitrator-validity-summary.html

25.6.16.2 ndbinfo 仲裁者有效性摘要表

arbitrator_validity_summary 表提供了关于集群数据节点的仲裁者的综合视图。

arbitrator_validity_summary 表包含以下列：

arbitrator
仲裁者的节点 ID
arb_ticket
用于跟踪仲裁的内部标识符
arb_connected
是否这个仲裁者连接到集群
consensus_count
视为仲裁者的数据节点数量；可能是Yes或No

备注

在正常操作中，这个表应该在相当长的时间内只有 1 行。如果在超过几分钟的时间内有多于 1 行，则可能是并非所有节点都连接到仲裁者，或者所有节点都连接了，但对同一个仲裁者意见不一致。

arbitrator 列显示仲裁者的节点 ID。

arb_ticket 是这个仲裁者使用的内部标识符。

arb_connected 显示这个节点是否作为仲裁者连接到集群。

原文：dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-backup-id.html

25.6.16.3 ndbinfo backup_id 表

该表提供了一种查找最近为该集群启动的备份的 ID 的方法。

backup_id 表包含一个名为 id 的单列，该列对应使用 ndb_mgm 客户端执行 START BACKUP 命令进行的备份 ID。该表包含一行。

示例: 假设在 NDB 管理客户端中发出以下一系列 START BACKUP 命令，自集群首次启动以来没有进行其他备份：

ndb_mgm> START BACKUP
Waiting for completed, this may take several minutes
Node 5: Backup 1 started from node 50
Node 5: Backup 1 started from node 50 completed
StartGCP: 27894 StopGCP: 27897
#Records: 2057 #LogRecords: 0
Data: 51580 bytes Log: 0 bytes
ndb_mgm> START BACKUP 5
Waiting for completed, this may take several minutes
Node 5: Backup 5 started from node 50
Node 5: Backup 5 started from node 50 completed
StartGCP: 27905 StopGCP: 27908
#Records: 2057 #LogRecords: 0
Data: 51580 bytes Log: 0 bytes
ndb_mgm> START BACKUP
Waiting for completed, this may take several minutes
Node 5: Backup 6 started from node 50
Node 5: Backup 6 started from node 50 completed
StartGCP: 27912 StopGCP: 27915
#Records: 2057 #LogRecords: 0
Data: 51580 bytes Log: 0 bytes
ndb_mgm> START BACKUP 3
Connected to Management Server at: localhost:1186
Waiting for completed, this may take several minutes
Node 5: Backup 3 started from node 50
Node 5: Backup 3 started from node 50 completed
StartGCP: 28149 StopGCP: 28152
#Records: 2057 #LogRecords: 0
Data: 51580 bytes Log: 0 bytes
ndb_mgm>

之后，使用 mysql 客户端，backup_id 表包含如下所示的单行：

mysql> USE ndbinfo;
Database changed
mysql> SELECT * FROM backup_id;
+——+
| id |
+——+
| 3 |
+——+
1 row in set (0.00 sec)

如果找不到任何备份，则表中包含一个 id 值为 0 的单行。

backup_id 表在 NDB 8.0.24 中添加。

原文：dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-blobs.html

25.6.16.4 ndbinfo blobs 表

此表提供了存储在NDB中的 blob 值的信息。blobs表包含以下列：

table_id
包含列的表的唯一 ID
database_name
此表所在的数据库的名称
table_name
表的名称
column_id
表内此列的唯一 ID
column_name
列的名称
inline_size
列的内联大小
part_size
列的部分大小
stripe_size
列的条带大小
blob_table_name
包含此列 blob 数据的 blob 表的名称（如果有）

此表中存在行，用于存储超过 255 字节的BLOB、TEXT值的NDB表列，因此需要使用 blob 表。超过 4000 字节的JSON值的部分也存储在此表中。有关 NDB 集群如何存储此类类型列的更多信息，请参阅字符串类型存储要求。

可以使用包含NDB表列注释的CREATE TABLE和ALTER TABLE语句设置NDB blob 列的部分和（NDB 8.0.30 及更高版本）内联大小（请参阅 NDB_COLUMN 选项）；这也可以在 NDB API 应用程序中完成（请参阅Column::setPartSize()和setInlineSize()）。

blobs表在 NDB 8.0.29 中添加。

原文：dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-blocks.html

25.6.16.5 ndbinfo 表

blocks 表是一个静态表，仅包含所有 NDB 内核块的名称和内部 ID（参见 NDB 内核块）。它供其他ndbinfo表（其中大部分实际上是视图）使用，以将块号映射到块名称，以生成人类可读的输出。

blocks 表包含以下列：

block_number
块号
block_name
块名称

笔记

要获取所有块名称的列表，只需执行SELECT block_name FROM ndbinfo.blocks。尽管这是一个静态表，但其内容可能会因不同的 NDB Cluster 版本而有所不同。

原文：dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-cluster-locks.html

25.6.16.6 ndbinfo cluster_locks表

cluster_locks表提供有关 NDB 集群中NDB表上持有和等待锁的当前锁请求的信息，并且旨在作为cluster_operations的伴随表。从cluster_locks表中获取的信息可能有助于调查停顿和死锁。

cluster_locks表包含以下列：

node_id
报告节点的 ID
block_instance
报告 LDM 实例的 ID
tableid
包含此行的表的 ID
fragmentid
包含锁定行的片段的 ID
rowid
锁定行的 ID
transid
事务 ID
mode
锁请求模式
state
锁定状态
detail
是否是排队中第一个持有锁的
op
操作类型
duration_millis
等待或持有锁的毫秒数
lock_num
锁对象的 ID
waiting_for
等待具有此 ID 的锁

备注

表 ID（tableid列）是内部分配的，与其他ndbinfo表中使用的相同。它也显示在ndb_show_tables的输出中。

事务 ID（transid列）是由 NDB API 为请求或持有当前锁的事务生成的标识符。

mode列显示锁模式；始终是S（表示共享锁）或X（独占锁）。如果事务对给定行持有独占锁，则该行上的所有其他锁都具有相同的事务 ID。

state列显示锁状态。其值始终是H（持有）或W（等待）。等待的锁请求等待由不同事务持有的锁。

当detail列包含*（星号字符）时，这意味着这个锁是受影响行锁队列中第一个持有的锁；否则，此列为空。此信息可用于帮助识别锁请求列表中的唯一条目。

op列显示请求锁的操作类型。始终是READ、INSERT、UPDATE、DELETE、SCAN或REFRESH中的一个值。

duration_millis列显示此锁请求等待或持有锁的毫秒数。当为等待请求授予锁时，此值将重置为 0。

锁 ID（lockid列）对于此节点和块实例是唯一的。

锁定状态显示在lock_state列中；如果是W，则表示锁正在等待授予，而waiting_for列显示此请求正在等待的锁对象的锁 ID。否则，waiting_for列为空。waiting_for只能指向同一行上的锁，由node_id、block_instance、tableid、fragmentid和rowid标识。

#以上关于MySQL8 中文参考（九十五）的相关内容来源网络仅供参考，相关信息请以官方公告为准！

原创文章，作者：CSDN，如若转载，请注明出处：https://www.sudun.com/ask/92437.html

MySQL8 中文参考（九十五）（mysql8.0中文手册）

25.6.11.2 NDB 集群磁盘数据存储要求

25.6.12 NDB 集群中的在线 ALTER TABLE 操作

NDB 在线操作的限制

25.6.13 权限同步和 NDB_STORED_USER

25.6.14 NDB 集群的文件系统加密

25.6.14.1 NDB 文件系统加密设置和使用

25.6.14.2 NDB 文件系统加密实现

25.6.14.3 NDB 文件系统加密限制

25.6.15 NDB API 统计计数器和变量

25.6.16 ndbinfo: NDB 集群信息数据库

25.6.16.1 ndbinfo arbitrator_validity_detail 表

备注

25.6.16.2 ndbinfo 仲裁者有效性摘要表

备注

25.6.16.3 ndbinfo backup_id 表

25.6.16.4 ndbinfo blobs 表

25.6.16.5 ndbinfo 表

笔记

25.6.16.6 ndbinfo cluster_locks表

备注

相关推荐

2024年天猫淘宝京东618什么时候开始，详细活动时间以及红包密码怎么玩

天天听说SEO，那么SEO到底是什么？

AI时代下的SEO（AI时代下的人生设计(斯坦福场)）

python学习BeautifulSoup解析框架html

发表回复