MySQL8 中文参考（九十七）

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

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

25.6.16.38 ndbinfo hwinfo 表

hwinfo表提供了关于给定数据节点所在硬件的信息。

hwinfo表包含以下列：

• node_id

  节点 ID

• cpu_cnt_max

  此主机上的处理器数量

• cpu_cnt

  此节点可用的处理器数量

• num_cpu_cores

  此主机上的 CPU 核心数

• num_cpu_sockets

  此主机上的 CPU 插槽数量

• HW_memory_size

  此主机上可用的内存量

• model_name

  CPU 型号名称

注意事项

hwinfo表在所有由NDB支持的操作系统上都可用。

此表在 NDB 8.0.23 中添加。

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

25.6.16.39 ndbinfo index_columns表

该表提供关于NDB表上的索引的信息。index_columns表的列在此处列出，并附有简要描述：

• table_id

  NDB表的唯一 ID，定义了该索引

• 包含此表的数据库的名称

  varchar(64)

• table_name

  表的名称

• index_object_id

  此索引的对象 ID

• index_name

  索引的名称；如果索引没有命名，则使用索引中的第一列的名称。

• index_type

  索引类型；通常为 3（唯一哈希索引）或 6（有序索引）；这些值与dict_obj_types表中的type_id列中的值相同

• status

  其中之一是new、changed、retrieved、invalid或altered

• columns

  由构成索引的列组成的逗号分隔列表

index_columns表在 NDB 8.0.29 中添加。

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

25.6.16.40 ndbinfo index_stats 表

index_stats 表提供关于 NDB 索引统计的基本信息。

使用 ndb_index_stat 实用程序可以获得更完整的索引统计信息。

index_stats 表包含以下列：

• index_id

  索引 ID

• index_version

  索引版本

• sample_version

  样本版本

注意

该表在 NDB 8.0.28 版本中添加。

dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-locks-per-fragment.html

25.6.16.41 The ndbinfo locks_per_fragment Table

locks_per_fragment 表提供了关于锁索赔请求计数以及这些请求的结果的信息，以每个片段为基础，作为 operations_per_fragment 和 memory_per_fragment 的伴随表。该表还显示了自片段或表创建以来成功和失败等待锁的总时间，或自最近一次重新启动以来的时间。

locks_per_fragment 表包含以下列：

• fq_name

  完全限定表名

• parent_fq_name

  父对象的完全限定名称

• type

  表类型；请参阅文本以获取可能的值

• table_id

  表 ID

• node_id

  报告节点 ID

• block_instance

  LDM 实例 ID

• fragment_num

  片段标识符

• ex_req

  排他锁请求已开始

• ex_imm_ok

  立即授予的排他锁请求

• ex_wait_ok

  等待后授予的排他锁请求

• ex_wait_fail

  未授予的排他锁请求

• sh_req

  已开始的共享锁请求

• sh_imm_ok

  立即授予的共享锁请求

• sh_wait_ok

  等待后授予的共享锁请求

• sh_wait_fail

  未授予共享锁请求

• wait_ok_millis

  等待授予的锁请求花费的时间，以毫秒为单位

• wait_fail_millis

  等待失败的锁请求花费的时间，以毫秒为单位

注意

block_instance 指的是内核块的一个实例。与块名���一起，此数字可用于在 threadblocks 表中查找给定实例。

fq_name 是以*database/schema/name*格式表示的完全限定数据库对象名称，例如 test/def/t1 或 sys/def/10/b$unique。

parent_fq_name 是此对象的父对象（表）的完全限定名称。

table_id 是由 NDB 生成的表的内部 ID。这是其他 ndbinfo 表中显示的相同内部表 ID；它也可在 ndb_show_tables 的输出中看到。

type 列显示表的类型。这始终是 System table、User table、Unique hash index、Hash index、Unique ordered index、Ordered index、Hash index trigger、Subscription trigger、Read only constraint、Index trigger、Reorganize trigger、Tablespace、Log file group、Data file、Undo file、Hash map、Foreign key definition、Foreign key parent trigger、Foreign key child trigger 或 Schema transaction 中的一个。

所有列ex_req、ex_req_imm_ok、ex_wait_ok、ex_wait_fail、sh_req、sh_req_imm_ok、sh_wait_ok和sh_wait_fail中显示的值代表自表或片段创建以来的累积请求次数，或自此节点上次重新启动以来的时间，以后者为准。对于wait_ok_millis和wait_fail_millis列中显示的时间值也是如此。

每个锁请求被认为是正在进行中，或以某种方式已经完成（即成功或失败）。这意味着以下关系是正确的：

ex_req >= (ex_req_imm_ok + ex_wait_ok + ex_wait_fail)

sh_req >= (sh_req_imm_ok + sh_wait_ok + sh_wait_fail)

当前正在进行的请求数量是当前未完成请求的数量，可以按照以下所示找到：

[exclusive lock requests in progress] =
    ex_req - (ex_req_imm_ok + ex_wait_ok + ex_wait_fail)

[shared lock requests in progress] =
    sh_req - (sh_req_imm_ok + sh_wait_ok + sh_wait_fail)

失败的等待表示一个中止的事务，但中止可能或可能不是由于锁等待超时引起的。您可以按照以下所示获取等待锁时中止的总数：

[aborts while waiting for locks] = ex_wait_fail + sh_wait_fail

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

25.6.16.42 ndbinfo 日志缓冲区表

logbuffer 表提供了关于 NDB 集群日志缓冲区使用情况的信息。

logbuffers 表包含以下列：

• node_id

  此数据节点的 ID。

• log_type

  日志类型。其中之一：REDO、DD-UNDO、BACKUP-DATA 或 BACKUP-LOG。

• log_id

  日志 ID；对于磁盘数据撤销日志文件，这与信息模式 FILES 表中的 LOGFILE_GROUP_NUMBER 列显示的值以及 ndbinfo logspaces 表的 log_id 列显示的值相同

• log_part

  日志部分编号

• total

  此日志可用的总空间

• used

  此日志使用的空间

笔记

在执行 NDB 备份时，logbuffers 表行反映了另外两种日志类型。其中一行具有日志类型 BACKUP-DATA，显示了在备份期间用于将片段复制到备份文件的数据缓冲区的使用量。另一行具有日志类型 BACKUP-LOG，显示了在备份开始后记录所做更改时备份期间使用的日志缓冲区的使用量。在集群中的每个数据节点的 logbuffers 表中分别显示了这些 log_type 行。除非当前正在执行 NDB 备份，否则这些行不会出现。

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

25.6.16.43 ndbinfo 日志空间表

该表提供了关于 NDB 集群日志空间使用情况的信息。

logspaces表包含以下列：

• node_id

  此数据节点的 ID。

• log_type

  日志类型；可以是REDO或DD-UNDO之一。

• node_id

  日志 ID；对于磁盘数据撤销日志文件，这与信息模式FILES表中的LOGFILE_GROUP_NUMBER列显示的值相同，以及ndbinfo logbuffers表中的log_id列显示的值相同

• log_part

  日志部分编号。

• total

  该日志可用的总空间。

• used

  此日志使用的空间。

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

25.6.16.44 ndbinfo membership 表

membership表描述了集群中每个数据节点对其他所有节点的视图，包括节点组成员资格、主节点、仲裁者、仲裁者后继、仲裁者连接状态和其他信息。

membership表包含以下列：

• node_id

  此节点的节点 ID

• group_id

  此节点所属的节点组

• left node

  前一个节点的节点 ID

• right_node

  下一个节点的节点 ID

• president

  主节点的节点 ID

• successor

  继任主席的节点 ID

• succession_order

  此节点继任主席的顺序

• Conf_HB_order

• arbitrator

  仲裁者的节点 ID

• arb_ticket

  用于跟踪仲裁的内部标识符

• arb_state

  仲裁状态

• arb_connected

  此节点是否连接到仲裁者；Yes或No中的任意一个

• connected_rank1_arbs

  一级仲裁者连接

• connected_rank2_arbs

  一级仲裁者连接

备注

节点 ID 和节点组 ID 与**ndb_mgm -e "SHOW"**报告的相同。

left_node和right_node根据连接所有数据节点的模型定义，按照节点 ID 的顺序连接成一个圆圈，类似于时钟表盘上数字的顺序，如下所示：

图 25.6 NDB 集群节点的循环排列

在此示例中，我们有 8 个数据节点，编号为 5、6、7、8、12、13、14 和 15，按顺时针顺序排列在一个圆圈中。我们从圆圈的内部确定“左”和“右”。节点 5 左侧的节点是节点 15，节点 5 右侧的节点是节点 6。您可以通过运行以下查询并观察输出来查看所有这些关系：

mysql> SELECT node_id,left_node,right_node
 -> FROM ndbinfo.membership;
+---------+-----------+------------+
| node_id | left_node | right_node |
+---------+-----------+------------+
|       5 |        15 |          6 |
|       6 |         5 |          7 |
|       7 |         6 |          8 |
|       8 |         7 |         12 |
|      12 |         8 |         13 |
|      13 |        12 |         14 |
|      14 |        13 |         15 |
|      15 |        14 |          5 |
+---------+-----------+------------+
8 rows in set (0.00 sec)

“左”和“右”这些称号在事件日志中以相同方式使用。

president节点是当前节点视为负责设置仲裁者的节点（参见 NDB 集群启动阶段）。如果主节点失败或断开连接，当前节点期望显示在successor列中的节点 ID 成为新的主节点。succession_order列显示当前节点视自己在继任队列中的位置。

在正常的 NDB 集群中，所有数据节点应该将相同的节点视为president，并将相同的节点（除了主节点）视为其successor。此外，当前主节点应该将自己视为继任顺序中的1，successor节点应该将自己视为2，依此类推。

所有节点应显示相同的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显示此节点是否连接到显示为此节点的arbitrator的节点。

connected_rank1_arbs和connected_rank2_arbs列分别显示一个或多个仲裁者的列表，这些仲裁者的ArbitrationRank分别等于 1 或 2。

注意

管理节点和 API 节点都有资格成为仲裁者。

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

25.6.16.45 ndbinfo memoryusage表

查询此表提供类似于ALL REPORT MemoryUsage命令在ndb_mgm客户端中提供的信息，或由ALL DUMP 1000记录的信息。

memoryusage表包含以下列：

• node_id

  此数据节点的节点 ID。

• memory_type

  Data memory、Index memory或Long message buffer中的一个。

• used

  此数据节点当前用于数据内存或索引内存的字节数。

• used_pages

  此数据节点当前用于数据内存或索引内存的页面数；参见文本。

• total

  数据节点可用的数据内存或索引内存的总字节数；参见文本。

• total_pages

  数据内存或索引内存在此数据节点上可用的内存页总数；参见文本。

注

total列表示特定数据节点上给定资源（数据内存或索引内存）的可用内存总量（以字节为单位）。此数字应大致等于config.ini文件中相应配置参数的设置。

假设集群有 2 个数据节点，节点 ID 分别为5和6，config.ini文件包含以下内容：

[ndbd default]
DataMemory = 1G
IndexMemory = 1G

还假设LongMessageBuffer配置参数的值允许采用其默认值（64 MB）。

以下查询显示大致相同的值：

mysql> SELECT node_id, memory_type, total
     > FROM ndbinfo.memoryusage;
+---------+---------------------+------------+
| node_id | memory_type         | total      |
+---------+---------------------+------------+
|       5 | Data memory         | 1073741824 |
|       5 | Index memory        | 1074003968 |
|       5 | Long message buffer |   67108864 |
|       6 | Data memory         | 1073741824 |
|       6 | Index memory        | 1074003968 |
|       6 | Long message buffer |   67108864 |
+---------+---------------------+------------+
6 rows in set (0.00 sec)

在这种情况下，索引内存的total列值略高于IndexMemory设置值，这是由于内部四舍五入导致的。

对于used_pages和total_pages列，资源以页面为单位进行度量，对于DataMemory为 32K，对于IndexMemory为 8K。对于长消息缓冲内存，页面大小为 256 字节。

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

25.6.16.46 ndbinfo memory_per_fragment 表

• memory_per_fragment 表：注释

• memory_per_fragment 表：示例

memory_per_fragment 表提供有关单个片段内存使用情况的信息。请参阅本节后面的 注释 以了解如何使用此信息查找 NDB 表使用了多少内存。

memory_per_fragment 表包含以下列：

• fq_name

  此片段的名称

• parent_fq_name

  此片段的父级名称

• type

  用于此片段的字典对象类型（Object::Type，在 NDB API 中）之一：System table、User table、Unique hash index、Hash index、Unique ordered index、Ordered index、Hash index trigger、Subscription trigger、Read only constraint、Index trigger、Reorganize trigger、Tablespace、Log file group、Data file、Undo file、Hash map、Foreign key definition、Foreign key parent trigger、Foreign key child trigger 或 Schema transaction。

  您还可以通过在 mysql 客户端中执行 TABLE ndbinfo.dict_obj_types 来获取此列表。

• table_id

  此表的表 ID

• node_id

  此节点的节点 ID

• block_instance

  NDB 内核块实例 ID；您可以使用此数字从 threadblocks 表中获取有关特定线程的信息。

• fragment_num

  片段 ID（数字）

• fixed_elem_alloc_bytes

  为固定大小元素分配的字节数

• fixed_elem_free_bytes

  分配给固定大小元素的页面中剩余的空闲字节数

• fixed_elem_size_bytes

  每个固定大小元素的字节长度

• fixed_elem_count

  固定大小元素的数量

• fixed_elem_free_count

  用于固定大小元素的空闲行数

• var_elem_alloc_bytes

  为可变大小元素分配的字节数

• var_elem_free_bytes

  分配给可变大小元素的页面中剩余的空闲字节数

• var_elem_count

  可变大小元素的数量

• hash_index_alloc_bytes

  为哈希索引分配的字节数

memory_per_fragment 表：注释

memory_per_fragment 表包含系统中每个表片段副本和每个索引片段副本的一行；这意味着，例如，当NoOfReplicas=2时，通常每个片段都有两个片段副本。只要所有数据节点都在运行并连接到集群，这一点就成立；对于缺失的数据节点，它承载的片段副本没有行。

memory_per_fragment 表的列可以根据其功能或目的分组如下：

• 键列：fq_name、type、table_id、node_id、block_instance和fragment_num

• 关系列：parent_fq_name

• 固定大小存储列：fixed_elem_alloc_bytes、fixed_elem_free_bytes、fixed_elem_size_bytes、fixed_elem_count和fixed_elem_free_count

• 可变大小存储列：var_elem_alloc_bytes、var_elem_free_bytes和var_elem_count

• 哈希索引列：hash_index_alloc_bytes

parent_fq_name 和 fq_name 列可用于识别与表关联的索引。类似的模式对象层次结构信息在其他ndbinfo表中也可用。

表和索引片段副本以 32KB 页面分配DataMemory。这些内存页面的管理如下所示：

• 固定大小页：这些存储在给定片段中存储的行的固定大小部分。每行都有一个固定大小部分。

• 可变大小页：这些为片段中的行存储可变大小部分。每行具有一个或多个可变大小部分，一个或多个动态列（或两者都有）的行具有可变大小部分。

• 哈希索引页：这些被分配为 8 KB 子页，存储主键哈希索引结构。

NDB表中的每行都有一个固定大小部分，包括行头和一个或多个固定大小列。该行还可能包含一个或多个变量大小部分引用，一个或多个磁盘部分引用，或两者都有。每行还有一个主键哈希索引条目（对应于每个NDB表中的隐藏主键）。

从前述内容我们可以看到，每个表片段和索引片段一起分配了根据此处计算的DataMemory数量：

DataMemory =
  (*number_of_fixed_pages* + *number_of_var_pages*) * 32KB
    + *number_of_hash_pages* * 8KB

由于fixed_elem_alloc_bytes和var_elem_alloc_bytes始终是 32768 字节的倍数，我们可以进一步确定*number_of_fixed_pages* = fixed_elem_alloc_bytes / 32768和*number_of_var_pages* = var_elem_alloc_bytes / 32768。hash_index_alloc_bytes始终是 8192 字节的倍数，因此*number_of_hash_pages* = hash_index_alloc_bytes / 8192。

固定大小页具有内部标头和多个固定大小槽，每个槽可以包含一行的固定大小部分。给定行的固定大小部分的大小取决于模式，并由fixed_elem_size_bytes列提供；每页的固定大小槽数量可以通过计算总槽数量和总页数来确定，如下所示：

*fixed_slots* = fixed_elem_count + fixed_elem_free_count

*fixed_pages* = fixed_elem_alloc_bytes / 32768

*slots_per_page* = total_slots / total_pages

fixed_elem_count实际上是给定表碎片的行数，因为每行有 1 个固定元素，fixed_elem_free_count是分配的页中所有固定大小空槽的总数。fixed_elem_free_bytes等于fixed_elem_free_count * fixed_elem_size_bytes。

一个碎片可以有任意数量的固定大小页；当固定大小页上的最后一行被删除时，该页将释放到DataMemory页池中。固定大小页可以被碎片化，分配的页比实际使用的固定大小槽数量多。您可以通过比较所需页数和分配的页数来检查是否是这种情况，计算方法如下：

*fixed_pages_required* = 1 + (fixed_elem_count / *slots_per_page*)

fixed_page_utilization = *fixed_pages_required* / *fixed_pages*

可变大小页具有内部标头，并使用剩余空间存储一个或多个可变大小行部分；存储的部分数量取决于模式和实际存储的数据。由于并非所有模式或行都有可变大小部分，var_elem_count可能小于fixed_elem_count。碎片中所有可变大小页上的总可用空间由var_elem_free_bytes列显示；因为此空间可能分布在多个页上，所以不能必然用于存储特定大小的条目。根据需要重新组织每个可变大小页，以适应插入、更新和删除可变大小行部分的变化大小；如果给定行部分增长到超出所在页的大小，则可以将其移动到另一页。

可变大小页的利用率可以按照这里所示进行计算：

*var_page_used_bytes* =  var_elem_alloc_bytes - var_elem_free_bytes

*var_page_utilisation* = var_page_used_bytes / var_elem_alloc_bytes

*avg_row_var_part_size* = *var_page_used_bytes* / fixed_elem_count

我们可以按照以下方式获得每行的平均可变部分大小：

*avg_row_var_part_size* = *var_page_used_bytes* / fixed_elem_count

次要唯一索引在内部实现为具有以下模式的独立表：

• 主键：基表中的索引列。

• 值：基表中的主键列。

这些表像普通表一样分布和碎片化。这意味着它们的碎片副本使用固定、可变和哈希索引页，就像任何其他NDB表一样。

次序有序索引与基表相同方式进行碎片化和分布。有序索引片段是维护平衡树的 T 树结构，其中包含按索引列暗示的顺序包含行引用。由于树包含引用而不是实际数据，因此 T 树存储成本不取决于索引列的大小或数量，而是取决于行数。树是使用固定大小节点结构构建的，每个节点可以包含多个行引用；所需的节点数量取决于表中的行数，以及表示排序所需的树结构。在memory_per_fragment表中，我们可以看到有序索引仅分配固定大小页面，因此像往常一样，此表中相关列如下所列：

• fixed_elem_alloc_bytes: 这等于固定大小页面的数量乘以 32768。

• fixed_elem_count: 正在使用的 T 树节点数。

• fixed_elem_size_bytes: 每个 T 树节点的字节数。

• fixed_elem_free_count: 分配的页面中可用的 T 树节点槽位数。

• fixed_elem_free_bytes: 这等于fixed_elem_free_count * fixed_elem_size_bytes。

如果页面中的空闲空间是碎片化的，则页面将被整理。OPTIMIZE TABLE可用于整理表的可变大小页面；这将在页面之间移动行的可变大小部分，以便一些整个页面可以被释放以供重新使用。

memory_per_fragment 表：示例

• 获取有关片段和内存使用情况的一般信息

• 查找表及其索引

• 查找模式元素分配的内存

• 查找表及其所有索引分配的内存

• 查找每行分配的内存

• 查找每行使用的总内存

• 查找每个元素分配的内存

• 按元素查找每行分配的平均内存

• 查找每行分配的平均内存

• 查找表格每行分配的平均内存

• 按每个模式元素查找使用的内存

• 按每个模式元素查找使用的平均内存

• 按元素查找每行使用的平均内存

• 查找每行使用的总平均内存

对于以下示例，我们创建一个简单的表格，包含三个整数列，其中一个具有主键，一个具有唯一索引，一个没有索引，以及一个没有索引的VARCHAR列，如下所示：

mysql> CREATE DATABASE IF NOT EXISTS test;
Query OK, 1 row affected (0.06 sec)

mysql> USE test;
Database changed

mysql> CREATE TABLE t1 (
 ->    c1 BIGINT NOT NULL AUTO_INCREMENT PRIMARY KEY,
 ->    c2 INT,
 ->    c3 INT UNIQUE,
 -> )  ENGINE=NDBCLUSTER;
Query OK, 0 rows affected (0.27 sec)

创建表格后，我们插入包含随机数据的 50,000 行；生成和插入这些行的确切方法在实际上没有任何区别，我们将完成方法的实现留给用户作为练习。

获取片段和内存使用的一般信息

此查询显示每个片段的内存使用情况的一般信息：

mysql> SELECT
 ->   fq_name, node_id, block_instance, fragment_num, fixed_elem_alloc_bytes,
 ->   fixed_elem_free_bytes, fixed_elem_size_bytes, fixed_elem_count,
 ->   fixed_elem_free_count, var_elem_alloc_bytes, var_elem_free_bytes,
 ->   var_elem_count
 -> FROM ndbinfo.memory_per_fragment
 -> WHERE fq_name = "test/def/t1"\G
*************************** 1\. row ***************************
               fq_name: test/def/t1
               node_id: 5
        block_instance: 1
          fragment_num: 0
fixed_elem_alloc_bytes: 1114112
 fixed_elem_free_bytes: 11836
 fixed_elem_size_bytes: 44
      fixed_elem_count: 24925
 fixed_elem_free_count: 269
  var_elem_alloc_bytes: 1245184
   var_elem_free_bytes: 32552
        var_elem_count: 24925
*************************** 2\. row ***************************
               fq_name: test/def/t1
               node_id: 5
        block_instance: 1
          fragment_num: 1
fixed_elem_alloc_bytes: 1114112
 fixed_elem_free_bytes: 5236
 fixed_elem_size_bytes: 44
      fixed_elem_count: 25075
 fixed_elem_free_count: 119
  var_elem_alloc_bytes: 1277952
   var_elem_free_bytes: 54232
        var_elem_count: 25075
*************************** 3\. row ***************************
               fq_name: test/def/t1
               node_id: 6
        block_instance: 1
          fragment_num: 0
fixed_elem_alloc_bytes: 1114112
 fixed_elem_free_bytes: 11836
 fixed_elem_size_bytes: 44
      fixed_elem_count: 24925
 fixed_elem_free_count: 269
  var_elem_alloc_bytes: 1245184
   var_elem_free_bytes: 32552
        var_elem_count: 24925
*************************** 4\. row ***************************
               fq_name: test/def/t1
               node_id: 6
        block_instance: 1
          fragment_num: 1
fixed_elem_alloc_bytes: 1114112
 fixed_elem_free_bytes: 5236
 fixed_elem_size_bytes: 44
      fixed_elem_count: 25075
 fixed_elem_free_count: 119
  var_elem_alloc_bytes: 1277952
   var_elem_free_bytes: 54232
        var_elem_count: 25075 4 rows in set (0.12 sec)

查找表格及其索引

此查询可用于查找特定表格及其索引：

mysql> SELECT fq_name
 -> FROM ndbinfo.memory_per_fragment
 -> WHERE fq_name = 'test/def/t1' OR parent_fq_name='test/def/t1'
 -> GROUP BY fq_name;
+----------------------+
| fq_name              |
+----------------------+
| test/def/t1          |
| sys/def/13/PRIMARY   |
| sys/def/13/c3        |
| sys/def/13/c3$unique |
+----------------------+
4 rows in set (0.13 sec)

mysql> SELECT COUNT(*) FROM t1;
+----------+
| COUNT(*) |
+----------+
|    50000 |
+----------+
1 row in set (0.00 sec)

查找模式元素分配的内存

此查询显示每个模式元素分配的内存（在所有副本中总计）：

mysql> SELECT
 ->   fq_name AS Name,
 ->   SUM(fixed_elem_alloc_bytes) AS Fixed,
 ->   SUM(var_elem_alloc_bytes) AS Var,
 ->   SUM(hash_index_alloc_bytes) AS Hash,
 ->   SUM(fixed_elem_alloc_bytes+var_elem_alloc_bytes+hash_index_alloc_bytes) AS Total
 -> FROM ndbinfo.memory_per_fragment
 -> WHERE fq_name = 'test/def/t1' OR parent_fq_name='test/def/t1'
 -> GROUP BY fq_name;
+----------------------+---------+---------+---------+----------+
| Name                 | Fixed   | Var     | Hash    | Total    |
+----------------------+---------+---------+---------+----------+
| test/def/t1          | 4456448 | 5046272 | 1425408 | 10928128 |
| sys/def/13/PRIMARY   | 1966080 |       0 |       0 |  1966080 |
| sys/def/13/c3        | 1441792 |       0 |       0 |  1441792 |
| sys/def/13/c3$unique | 3276800 |       0 | 1425408 |  4702208 |
+----------------------+---------+---------+---------+----------+
4 rows in set (0.11 sec)

查找为表格及所有索引分配的内存

可以使用以下查询获取为表格及其所有索引分配的内存总和（在所有副本中总计）：

mysql> SELECT
 ->   SUM(fixed_elem_alloc_bytes) AS Fixed,
 ->   SUM(var_elem_alloc_bytes) AS Var,
 ->   SUM(hash_index_alloc_bytes) AS Hash,
 ->   SUM(fixed_elem_alloc_bytes+var_elem_alloc_bytes+hash_index_alloc_bytes) AS Total
 -> FROM ndbinfo.memory_per_fragment
 -> WHERE fq_name = 'test/def/t1' OR parent_fq_name='test/def/t1';
+----------+---------+---------+----------+
| Fixed    | Var     | Hash    | Total    |
+----------+---------+---------+----------+
| 11141120 | 5046272 | 2850816 | 19038208 |
+----------+---------+---------+----------+
1 row in set (0.12 sec)

这是前一个查询的简化版本，仅显示表格使用的总内存：

mysql> SELECT
 ->   SUM(fixed_elem_alloc_bytes+var_elem_alloc_bytes+hash_index_alloc_bytes) AS Total
 -> FROM ndbinfo.memory_per_fragment
 -> WHERE fq_name = 'test/def/t1' OR parent_fq_name='test/def/t1';
+----------+
| Total    |
+----------+
| 19038208 |
+----------+
1 row in set (0.12 sec)

查找每行分配的内存

以下查询显示每行分配的总内存（在所有副本中）：

mysql> SELECT
 ->   SUM(fixed_elem_alloc_bytes+var_elem_alloc_bytes+hash_index_alloc_bytes)
 ->   /
 ->   SUM(fixed_elem_count) AS Total_alloc_per_row
 -> FROM ndbinfo.memory_per_fragment
 -> WHERE fq_name = 'test/def/t1';
+---------------------+
| Total_alloc_per_row |
+---------------------+
|            109.2813 |
+---------------------+
1 row in set (0.12 sec)

查找每行使用的总内存

要获取每行使用的总内存（在所有副本中），我们需要将总内存使用量除以行数，即基本表的fixed_elem_count，如下所示：

mysql> SELECT
 ->   SUM(
 ->     (fixed_elem_alloc_bytes - fixed_elem_free_bytes)
 ->     + (var_elem_alloc_bytes - var_elem_free_bytes)
 ->     + hash_index_alloc_bytes
 ->   )
 ->   /
 ->   SUM(fixed_elem_count)
 ->   AS total_in_use_per_row
 -> FROM ndbinfo.memory_per_fragment
 -> WHERE fq_name = 'test/def/t1';
+----------------------+
| total_in_use_per_row |
+----------------------+
|             107.2042 |
+----------------------+
1 row in set (0.12 sec)

查找每个元素分配的内存

每个模式元素分配的内存（在所有副本中总共）可以使用以下查询找到：

mysql> SELECT
 ->   fq_name AS Name,
 ->   SUM(fixed_elem_alloc_bytes) AS Fixed,
 ->   SUM(var_elem_alloc_bytes) AS Var,
 ->   SUM(hash_index_alloc_bytes) AS Hash,
 ->   SUM(fixed_elem_alloc_bytes + var_elem_alloc_bytes + hash_index_alloc_bytes)
 ->     AS Total_alloc
 -> FROM ndbinfo.memory_per_fragment
 -> WHERE fq_name = 'test/def/t1' OR parent_fq_name='test/def/t1'
 -> GROUP BY fq_name;
+----------------------+---------+---------+---------+-------------+
| Name                 | Fixed   | Var     | Hash    | Total_alloc |
+----------------------+---------+---------+---------+-------------+
| test/def/t1          | 4456448 | 5046272 | 1425408 |    10928128 |
| sys/def/13/PRIMARY   | 1966080 |       0 |       0 |     1966080 |
| sys/def/13/c3        | 1441792 |       0 |       0 |     1441792 |
| sys/def/13/c3$unique | 3276800 |       0 | 1425408 |     4702208 |
+----------------------+---------+---------+---------+-------------+
4 rows in set (0.11 sec)

按元素查找每行分配的平均内存

要获取每个模式元素分配的平均每行内存（在所有副本中），我们使用子查询每次获取基本表固定元素计数以获得每行平均值，因为索引的fixed_elem_count不一定与基本表相同，如下所示：

mysql> SELECT
 ->   fq_name AS Name,
 ->   ( SELECT SUM(fixed_elem_count)
 ->     FROM ndbinfo.memory_per_fragment
 ->     WHERE fq_name='test/def/t1') AS Table_rows,
 ->
 ->   SUM(fixed_elem_alloc_bytes)
 ->   /
 ->   ( SELECT SUM(fixed_elem_count)
 ->     FROM ndbinfo.memory_per_fragment
 ->     WHERE fq_name='test/def/t1') AS Avg_fixed_alloc,
 ->
 ->   SUM(var_elem_alloc_bytes)
 ->   /
 ->   ( SELECT SUM(fixed_elem_count)
 ->     FROM ndbinfo.memory_per_fragment
 ->     WHERE fq_name='test/def/t1') as Avg_var_alloc,
 ->
 ->   SUM(hash_index_alloc_bytes)
 ->   /
 ->   ( SELECT SUM(fixed_elem_count)
 ->     FROM ndbinfo.memory_per_fragment
 ->     WHERE fq_name='test/def/t1') as Avg_hash_alloc,
 ->
 ->   SUM(fixed_elem_alloc_bytes+var_elem_alloc_bytes+hash_index_alloc_bytes)
 ->   /
 ->   ( SELECT SUM(fixed_elem_count)
 ->     FROM ndbinfo.memory_per_fragment
 ->     WHERE fq_name='test/def/t1') as Avg_total_alloc
 ->
 -> FROM ndbinfo.memory_per_fragment
 -> WHERE fq_name = 'test/def/t1' or parent_fq_name='test/def/t1'
 -> GROUP BY fq_name;
+----------------------+------------+-----------------+---------------+----------------+-----------------+
| Name                 | Table_rows | Avg_fixed_alloc | Avg_var_alloc | Avg_hash_alloc | Avg_total_alloc |
+----------------------+------------+-----------------+---------------+----------------+-----------------+
| test/def/t1          |     100000 |         44.5645 |       50.4627 |        14.2541 |        109.2813 |
| sys/def/13/PRIMARY   |     100000 |         19.6608 |        0.0000 |         0.0000 |         19.6608 |
| sys/def/13/c3        |     100000 |         14.4179 |        0.0000 |         0.0000 |         14.4179 |
| sys/def/13/c3$unique |     100000 |         32.7680 |        0.0000 |        14.2541 |         47.0221 |
+----------------------+------------+-----------------+---------------+----------------+-----------------+
4 rows in set (0.70 sec)

按行查找每行分配的平均内存

每行分配的平均内存（在所有副本中总共）：

mysql> SELECT
 ->   ( SELECT SUM(fixed_elem_count)
 ->     FROM ndbinfo.memory_per_fragment
 ->     WHERE fq_name='test/def/t1') AS Table_rows,
 ->
 ->   SUM(fixed_elem_alloc_bytes)
 ->   /
 ->   ( SELECT SUM(fixed_elem_count)
 ->     FROM ndbinfo.memory_per_fragment
 ->     WHERE fq_name='test/def/t1') AS Avg_fixed_alloc,
 ->
 ->   SUM(var_elem_alloc_bytes)
 ->   /
 ->   ( SELECT SUM(fixed_elem_count)
 ->     FROM ndbinfo.memory_per_fragment
 ->     WHERE fq_name='test/def/t1') AS Avg_var_alloc,
 ->
 ->   SUM(hash_index_alloc_bytes)
 ->   /
 ->   ( SELECT SUM(fixed_elem_count)
 ->     FROM ndbinfo.memory_per_fragment
 ->     WHERE fq_name='test/def/t1') AS Avg_hash_alloc,
 ->
 ->   SUM(fixed_elem_alloc_bytes + var_elem_alloc_bytes + hash_index_alloc_bytes)
 ->   /
 ->   ( SELECT SUM(fixed_elem_count)
 ->     FROM ndbinfo.memory_per_fragment
 ->     WHERE fq_name='test/def/t1') AS Avg_total_alloc
 ->
 -> FROM ndbinfo.memory_per_fragment
 -> WHERE fq_name = 'test/def/t1' OR parent_fq_name='test/def/t1';
+------------+-----------------+---------------+----------------+-----------------+
| Table_rows | Avg_fixed_alloc | Avg_var_alloc | Avg_hash_alloc | Avg_total_alloc |
+------------+-----------------+---------------+----------------+-----------------+
|     100000 |        111.4112 |       50.4627 |        28.5082 |        190.3821 |
+------------+-----------------+---------------+----------------+-----------------+
1 row in set (0.71 sec)

查找表格每行分配的平均内存

要获取整个表中每行分配的平均内存（在所有副本中），我们可以使用这里显示的查询：

mysql> SELECT
 ->   ( SELECT SUM(fixed_elem_count)
 ->     FROM ndbinfo.memory_per_fragment
 ->     WHERE fq_name='test/def/t1') AS table_rows,
 ->
 ->   SUM(fixed_elem_alloc_bytes + var_elem_alloc_bytes + hash_index_alloc_bytes)
 ->   /
 ->   ( SELECT SUM(fixed_elem_count)
 ->     FROM ndbinfo.memory_per_fragment
 ->     WHERE fq_name='test/def/t1') AS avg_total_alloc
 ->
 -> FROM ndbinfo.memory_per_fragment
 -> WHERE fq_name = 'test/def/t1' OR parent_fq_name='test/def/t1';
+------------+-----------------+
| table_rows | avg_total_alloc |
+------------+-----------------+
|     100000 |        190.3821 |
+------------+-----------------+
1 row in set (0.33 sec)

查找每个模式元素使用的内存

要获取所有副本中每个模式元素使用的内存，我们需要对每个元素的分配和空闲内存之间的差值求和，如下所示：

mysql> SELECT
 ->   fq_name AS Name,
 ->   SUM(fixed_elem_alloc_bytes - fixed_elem_free_bytes) AS fixed_inuse,
 ->   SUM(var_elem_alloc_bytes-var_elem_free_bytes) AS var_inuse,
 ->   SUM(hash_index_alloc_bytes) AS hash_memory,
 ->   SUM(  (fixed_elem_alloc_bytes - fixed_elem_free_bytes)
 ->       + (var_elem_alloc_bytes - var_elem_free_bytes)
 ->       + hash_index_alloc_bytes) AS total_alloc
 -> FROM ndbinfo.memory_per_fragment
 -> WHERE fq_name = 'test/def/t1' OR parent_fq_name='test/def/t1'
 -> GROUP BY fq_name;
+----------------------+-------------+-----------+---------+-------------+
| fq_name              | fixed_inuse | var_inuse | hash    | total_alloc |
+----------------------+-------------+-----------+---------+-------------+
| test/def/t1          |     4422304 |   4872704 | 1425408 |    10720416 |
| sys/def/13/PRIMARY   |     1950848 |         0 |       0 |     1950848 |
| sys/def/13/c3        |     1428736 |         0 |       0 |     1428736 |
| sys/def/13/c3$unique |     3212800 |         0 | 1425408 |     4638208 |
+----------------------+-------------+-----------+---------+-------------+
4 rows in set (0.13 sec)

按每个模式元素查找使用的平均内存

这个查询获取所有副本中每个模式元素使用的平均内存：

mysql> SELECT
 ->   fq_name AS Name,
 ->
 ->   ( SELECT SUM(fixed_elem_count)
 ->     FROM ndbinfo.memory_per_fragment
 ->     WHERE fq_name='test/def/t1') AS table_rows,
 ->
 ->   SUM(fixed_elem_alloc_bytes - fixed_elem_free_bytes)
 ->   /
 ->   ( SELECT SUM(fixed_elem_count)
 ->     FROM ndbinfo.memory_per_fragment
 ->     WHERE fq_name='test/def/t1') AS avg_fixed_inuse,
 ->
 ->   SUM(var_elem_alloc_bytes - var_elem_free_bytes)
 ->   /
 ->   ( SELECT SUM(fixed_elem_count)
 ->     FROM ndbinfo.memory_per_fragment
 ->     WHERE fq_name='test/def/t1') AS avg_var_inuse,
 ->
 ->   SUM(hash_index_alloc_bytes)
 ->   /
 ->   ( SELECT SUM(fixed_elem_count)
 ->     FROM ndbinfo.memory_per_fragment
 ->     WHERE fq_name='test/def/t1') AS avg_hash,
 ->
 ->   SUM(
 ->       (fixed_elem_alloc_bytes - fixed_elem_free_bytes)
 ->     + (var_elem_alloc_bytes - var_elem_free_bytes) + hash_index_alloc_bytes)
 ->   /
 ->   ( SELECT SUM(fixed_elem_count)
 ->     FROM ndbinfo.memory_per_fragment
 ->     WHERE fq_name='test/def/t1') AS avg_total_inuse
 ->
 -> FROM ndbinfo.memory_per_fragment
 -> WHERE fq_name = 'test/def/t1' OR parent_fq_name='test/def/t1'
 -> GROUP BY fq_name;
+----------------------+------------+-----------------+---------------+----------+-----------------+
| Name                 | table_rows | avg_fixed_inuse | avg_var_inuse | avg_hash | avg_total_inuse |
+----------------------+------------+-----------------+---------------+----------+-----------------+
| test/def/t1          |     100000 |         44.2230 |       48.7270 |  14.2541 |        107.2042 |
| sys/def/13/PRIMARY   |     100000 |         19.5085 |        0.0000 |   0.0000 |         19.5085 |
| sys/def/13/c3        |     100000 |         14.2874 |        0.0000 |   0.0000 |         14.2874 |
| sys/def/13/c3$unique |     100000 |         32.1280 |        0.0000 |  14.2541 |         46.3821 |
+----------------------+------------+-----------------+---------------+----------+-----------------+
4 rows in set (0.72 sec)

按元素查找每行使用的平均内存

这个查询获取所有副本中每行按元素使用的平均内存：

mysql> SELECT
 ->   ( SELECT SUM(fixed_elem_count)
 ->     FROM ndbinfo.memory_per_fragment
 ->     WHERE fq_name='test/def/t1') AS table_rows,
 ->
 ->   SUM(fixed_elem_alloc_bytes - fixed_elem_free_bytes)
 ->   /
 ->   ( SELECT SUM(fixed_elem_count)
 ->     FROM ndbinfo.memory_per_fragment
 ->     WHERE fq_name='test/def/t1') AS avg_fixed_inuse,
 ->
 ->   SUM(var_elem_alloc_bytes - var_elem_free_bytes)
 ->   /
 ->   ( SELECT SUM(fixed_elem_count)
 ->     FROM ndbinfo.memory_per_fragment
 ->     WHERE fq_name='test/def/t1') AS avg_var_inuse,
 ->
 ->   SUM(hash_index_alloc_bytes)
 ->   /
 ->   ( SELECT SUM(fixed_elem_count)
 ->     FROM ndbinfo.memory_per_fragment
 ->     WHERE fq_name='test/def/t1') AS avg_hash,
 ->
 ->   SUM(
 ->     (fixed_elem_alloc_bytes - fixed_elem_free_bytes)
 ->     + (var_elem_alloc_bytes - var_elem_free_bytes)
 ->     + hash_index_alloc_bytes)
 ->   /
 ->   ( SELECT SUM(fixed_elem_count)
 ->     FROM ndbinfo.memory_per_fragment
 ->     WHERE fq_name='test/def/t1') AS avg_total_inuse
 ->
 -> FROM ndbinfo.memory_per_fragment
 -> WHERE fq_name = 'test/def/t1' OR parent_fq_name='test/def/t1';
+------------+-----------------+---------------+----------+-----------------+
| table_rows | avg_fixed_inuse | avg_var_inuse | avg_hash | avg_total_inuse |
+------------+-----------------+---------------+----------+-----------------+
|     100000 |        110.1469 |       48.7270 |  28.5082 |        187.3821 |
+------------+-----------------+---------------+----------+-----------------+
1 row in set (0.68 sec)

查找每行使用的总平均内存

这个查询获取每行使用的总平均内存：

mysql> SELECT
 ->   SUM(
 ->     (fixed_elem_alloc_bytes - fixed_elem_free_bytes)
 ->     + (var_elem_alloc_bytes - var_elem_free_bytes)
 ->     + hash_index_alloc_bytes)
 ->   /
 ->   ( SELECT
 ->       SUM(fixed_elem_count)
 ->       FROM ndbinfo.memory_per_fragment
 ->       WHERE fq_name='test/def/t1') AS avg_total_in_use
 -> FROM ndbinfo.memory_per_fragment
 -> WHERE fq_name = 'test/def/t1' OR parent_fq_name='test/def/t1';
+------------------+
| avg_total_in_use |
+------------------+
|         187.3821 |
+------------------+
1 row in set (0.24 sec)

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

25.6.16.47 ndbinfo nodes 表

该表包含数据节点状态的信息。对于在集群中运行的每个数据节点，该表中的相应行提供节点的节点 ID、状态和运行时间。对于正在启动的节点，还显示当前的启动阶段。

nodes表包含以下列：

• node_id

  集群中数据节点的唯一节点 ID。

• uptime

  节点自上次启动以来的时间，以秒为单位。

• status

  数据节点的当前状态；请参阅文本以获取可能的值。

• start_phase

  如果数据节点正在启动，当前的启动阶段。

• config_generation

  在此数据节点上使用的集群配置文件的版本。

注意

uptime列显示自上次启动或重新启动以来该节点运行的时间（以秒为单位）。这是一个BIGINT - INTEGER, INT, SMALLINT, TINYINT, MEDIUMINT, BIGINT")值。这个数字包括实际启动节点所需的时间；换句话说，这个计数器从第一次调用ndbd或ndbmtd")开始运行；因此，即使对于尚未完成启动的节点，uptime可能显示一个非零值。

status列显示节点的当前状态。这是其中之一：NOTHING、CMVMI、STARTING、STARTED、SINGLEUSER、STOPPING_1、STOPPING_2、STOPPING_3或STOPPING_4。当状态为STARTING时，您可以在start_phase列中看到当前的启动阶段（请参见本节后面的内容）。当集群处于单用户模式时（请参阅第 25.6.6 节，“NDB 集群单用户模式”），所有数据节点的status列中都显示SINGLEUSER。看到STOPPING状态之一并不一定意味着节点正在关闭，而可能意味着它正在进入新状态。例如，如果将集群置于单用户模式，有时可以看到数据节点在状态短暂报告为STOPPING_2，然后状态更改为SINGLEUSER。

start_phase列使用与ndb_mgm客户端*node_id* STATUS命令输出中使用的相同值范围（请参见第 25.6.1 节，“NDB 集群管理客户端中的命令”）。如果节点当前未启动，则此列显示0。有关带有描述的 NDB 集群启动阶段的列表，请参见第 25.6.4 节，“NDB 集群启动阶段摘要”。

config_generation列显示每个数据节点上生效的集群配置版本。在执行集群滚动重启以更改配置参数时，这可能很有用。例如，从以下SELECT语句的输出中，您可以看到节点 3 尚未使用最新版本的集群配置（6），尽管节点 1、2 和 4 正在使用：

mysql> USE ndbinfo;
Database changed
mysql> SELECT * FROM nodes;
+---------+--------+---------+-------------+-------------------+
| node_id | uptime | status  | start_phase | config_generation |
+---------+--------+---------+-------------+-------------------+
|       1 |  10462 | STARTED |           0 |                 6 |
|       2 |  10460 | STARTED |           0 |                 6 |
|       3 |  10457 | STARTED |           0 |                 5 |
|       4 |  10455 | STARTED |           0 |                 6 |
+---------+--------+---------+-------------+-------------------+
2 rows in set (0.04 sec)

因此，对于刚刚显示的情况，您应重新启动节点 3 以完成集群的滚动重启。

停止的节点不在此表中列出。假设您有一个具有 4 个数据节点（节点 ID 为 1、2、3 和 4）的 NDB 集群，并且所有节点正常运行，则此表包含 4 行，每个数据节点一行：

mysql> USE ndbinfo;
Database changed
mysql> SELECT * FROM nodes;
+---------+--------+---------+-------------+-------------------+
| node_id | uptime | status  | start_phase | config_generation |
+---------+--------+---------+-------------+-------------------+
|       1 |  11776 | STARTED |           0 |                 6 |
|       2 |  11774 | STARTED |           0 |                 6 |
|       3 |  11771 | STARTED |           0 |                 6 |
|       4 |  11769 | STARTED |           0 |                 6 |
+---------+--------+---------+-------------+-------------------+
4 rows in set (0.04 sec)

如果关闭其中一个节点，则此SELECT语句的输出中仅表示仍在运行的节点，如下所示：

ndb_mgm> 2 STOP
Node 2: Node shutdown initiated
Node 2: Node shutdown completed.
Node 2 has shutdown.

mysql> SELECT * FROM nodes;
+---------+--------+---------+-------------+-------------------+
| node_id | uptime | status  | start_phase | config_generation |
+---------+--------+---------+-------------+-------------------+
|       1 |  11807 | STARTED |           0 |                 6 |
|       3 |  11802 | STARTED |           0 |                 6 |
|       4 |  11800 | STARTED |           0 |                 6 |
+---------+--------+---------+-------------+-------------------+
3 rows in set (0.02 sec)

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

25.6.16.48 ndbinfo operations_per_fragment 表

operations_per_fragment表提供有关对各个片段和片段副本执行的操作以及一些操作结果的信息。

operations_per_fragment表包含以下列：

• fq_name

  此片段的名称

• parent_fq_name

  此片段的父级名称

• type

  对象类型；请参阅文本以获取可能的值

• table_id

  此表的表 ID

• node_id

  此节点的节点 ID

• block_instance

  内核块实例 ID

• fragment_num

  片段 ID（数字）

• tot_key_reads

  此片段副本的总键读取次数

• tot_key_inserts

  此片段副本的总键插入次数

• tot_key_updates

  此片段副本的总键更新次数

• tot_key_writes

  此片段副本的总键写入次数

• tot_key_deletes

  此片段副本的总键删除次数

• tot_key_refs

  拒绝的键操作次数

• tot_key_attrinfo_bytes

  所有attrinfo属性的总大小

• tot_key_keyinfo_bytes

  所有keyinfo属性的总大小

• tot_key_prog_bytes

  所有attrinfo属性携带的解释程序的总大小

• tot_key_inst_exec

  由键操作的解释程序执行的指令总数

• tot_key_bytes_returned

  从键读取操作返回的所有数据和元数据的总大小

• tot_frag_scans

  此片段副本执行的扫描总数

• tot_scan_rows_examined

  扫描检查的总行数

• tot_scan_rows_returned

  返回给客户端的总行数

• tot_scan_bytes_returned

  返回给客户端的数据和元数据的总大小

• tot_scan_prog_bytes

  扫描操作的解释程序的总大小

• tot_scan_bound_bytes

  有序索引扫描中使用的所有边界的总大小

• tot_scan_inst_exec

  扫描执行的指令总数

• tot_qd_frag_scans

  此片段副本扫描排队的次数

• conc_frag_scans

  当前在此片段副本上活动的扫描数（不包括排队扫描）

• conc_qd_frag_scans

  当前为此片段副本排队的扫描数

• 提交总数

  提交给此片段副本的行更改总数

注意

fq_name包含此片段副本所属的模式对象的完全限定名称。目前具有以下格式：

• 基表：*DbName*/def/*TblName*

• BLOB表：*DbName*/def/NDB$BLOB_*BaseTblId*_*ColNo*

• 有序索引：sys/def/*BaseTblId*/*IndexName*

• 唯一索引：sys/def/*BaseTblId*/*IndexName*$unique

唯一索引显示的$unique后缀是由mysqld添加的；对于由不同 NDB API 客户端应用程序创建的索引，可能会有所不同，或者不存在。

刚刚显示的完全限定对象名称的语法是一个内部接口，可能会在未来版本中更改。

考虑由以下 SQL 语句创建和修改的表t1：

CREATE DATABASE mydb;

USE mydb;

CREATE TABLE t1 (
  a INT NOT NULL,
  b INT NOT NULL,
  t TEXT NOT NULL,
  PRIMARY KEY (b)
) ENGINE=ndbcluster;

CREATE UNIQUE INDEX ix1 ON t1(b) USING HASH;

如果t1被分配表 ID 11，则这里显示的fq_name值为：

• 基本表：mydb/def/t1

• BLOB表：mydb/def/NDB$BLOB_11_2

• 有序索引（主键）：sys/def/11/PRIMARY

• 唯一索引：sys/def/11/ix1$unique

对于索引或BLOB表，parent_fq_name列包含相应基本表的fq_name。对于基本表，此列始终为NULL。

type列显示了用于此片段的模式对象类型，可以取以下任一值：System table、User table、Unique hash index或Ordered index。BLOB表显示为User table。

table_id列值在任何给定时间都是唯一的，但如果相应对象已被删除，则可以重新使用。可以使用ndb_show_tables实用程序查看相同的 ID。

block_instance列显示此片段副本属于哪个 LDM 实例。您可以使用此信息从threadblocks表中获取有关特定线程的信息。第一个这样的实例始终编号为 0。

由于通常有两个片段副本，并假设是这样，每个fragment_num值应在表中出现两次，分别在来自同一节点组的两个不同数据节点上。

由于NDB不使用单键访问有序索引，因此有序索引操作不会增加tot_key_reads、tot_key_inserts、tot_key_updates、tot_key_writes和tot_key_deletes的计数。

注意

在使用tot_key_writes时，应注意在此上下文中，写操作会更新行（如果键存在），否则会插入新行。（这在NDB实现的REPLACE SQL 语句中有用途。）

tot_key_refs列显示 LDM 拒绝的键操作数量。通常，这种拒绝是由于重复键（插入）、未找到键错误（更新、删除和读取）或操作被用作谓词的解释程序拒绝的。

tot_key_attrinfo_bytes 和 tot_key_keyinfo_bytes 列计算的 attrinfo 和 keyinfo 属性是 LQHKEYREQ 信号的属性（参见 NDB 通信协议），用于由 LDM 发起的键操作。attrinfo 通常包含元组字段值（插入和更新）或投影规范（用于读取）；keyinfo 包含在此模式对象中定位给定元组所需的主键或唯一键。

tot_frag_scans 显示的值包括全扫描（检查每一行）和子集扫描。唯一索引和 BLOB 表永远不会被扫描，因此对于这些片段副本，该值以及其他与扫描相关的计数都为 0。

tot_scan_rows_examined 可能显示的行数少于给定片段副本中的总行数，因为有序索引扫描可能受到边界限制。此外，客户端可能选择在检查所有潜在匹配行之前结束扫描；例如，在使用包含 LIMIT 或 EXISTS 子句的 SQL 语句时会发生这种情况。tot_scan_rows_returned 总是小于或等于 tot_scan_rows_examined。

tot_scan_bytes_returned 包括在推送连接中返回给 NDB 内核中的 DBSPJ 块的投影。

tot_qd_frag_scans 可受到 MaxParallelScansPerFragment 数据节点配置参数的设置影响，该参数限制了在单个片段副本上可以同时执行的扫描数量。

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

25.6.16.49 ndbinfo pgman_time_track_stats 表

该表提供有关 NDB Cluster Disk Data 表空间磁盘操作延迟的信息。

pgman_time_track_stats 表包含以下列：

• node_id

  集群中此节点的唯一节点 ID

• block_number

  块编号（来自 blocks 表）

• block_instance

  块实例编号

• upper_bound

  上限

• page_reads

  页面读取延迟（毫秒）

• page_writes

  页面写入延迟（毫秒）

• log_waits

  日志等待延迟（毫秒）

• get_page

  get_page() 调用的延迟（毫秒）

注意

读取延迟（page_reads 列）衡量了从发送读取请求到文件系统线程直到读取完成并报告给执行线程的时间。写入延迟（page_writes）以类似的方式计算。从磁盘数据表空间读取或写入的页面大小始终为 32 KB。

日志等待延迟（log_waits 列）是页面写入必须等待撤销日志刷新的时间长度，这必须在每次页面写入之前完成。

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

25.6.16.50 ndbinfo 进程表

此表包含有关 NDB Cluster 节点进程的信息；每个节点在表中由一行表示。仅显示连接到集群的节点在此表中。您可以从nodes和config_nodes表中获取有关已配置但未连接到集群的节点的信息。

processes表包含以下列：

• node_id

  集群中节点的唯一节点 ID

• node_type

  节点类型（管理、数据或 API 节点；参见文本）

• node_version

  NDB软件程序在此节点上运行的版本。

• process_id

  此节点的进程 ID

• angel_process_id

  此节点的 angel 进程的进程 ID

• process_name

  可执行文件的名称

• service_URI

  此节点的服务 URI（参见文本）

备注

node_id是分配给此节点的 ID。

node_type列显示以下三个值之一：

• MGM：管理节点。

• NDB：数据节点。

• API：API 或 SQL 节点。

对于 NDB Cluster 发行版附带的可执行文件，node_version显示软件 Cluster 版本字符串，例如8.0.35-ndb-8.0.35。

process_id是节点可执行文件的进程 ID，可以通过主机操作系统使用像 Linux 上的top或 Windows 平台上的任务管理器这样的进程显示应用程序来显示。

angel_process_id是节点的 angel 进程的系统进程 ID，它确保在发生故障时数据节点或 SQL 自动重新启动。对于管理节点和 SQL 节点以外的其他类型的 API 节点，此列的值为NULL。

process_name列显示正在运行的可执行文件的名称。对于管理节点，这是ndb_mgmd。对于数据节点，这是ndbd（单线程）或ndbmtd（多线程）。对于 SQL 节点，这是mysqld。对于其他类型的 API 节点，它是连接到集群的可执行程序的名称；NDB API 应用程序可以使用Ndb_cluster_connection::set_name()设置此列的自定义值。

service_URI显示了服务网络地址。对于管理节点和数据节点，使用的方案是ndb://。对于 SQL 节点，使用的是mysql://。默认情况下，除 SQL 节点外的 API 节点使用ndb://作为方案；NDB API 应用程序可以使用Ndb_cluster_connection::set_service_uri()将其设置为自定义值。无论节点类型如何，方案后面都是 NDB 传输器用于该节点的 IP 地址。对于管理节点和 SQL 节点，此地址包括端口号（通常为管理节点的 1186 和 SQL 节点的 3306）。如果 SQL 节点是使用bind_address系统变量启动的，则使用此地址而不是传输器地址，除非绑定地址设置为*、0.0.0.0或::。

附加路径信息可以包含在service_URI值中，反映了 SQL 节点的各种配置选项。例如，mysql://198.51.100.3/tmp/mysql.sock表示 SQL 节点是使用skip_networking系统变量启动的，而mysql://198.51.100.3:3306/?server-id=1表明该 SQL 节点启用了复制功能。

dev.mysql.com/doc/refman/8.0/en/mysql-cluster-ndbinfo-resources.html

25.6.16.51 ndbinfo 资源表

此表提供有关数据节点资源可用性和使用情况的信息。

这些资源有时被称为超级池。

resources表包含以下列：

• node_id

  此数据节点的唯一节点 ID。

• resource_name

  资源的名称；参见文本。

• reserved

  为此资源保留的 32KB 页面数。

• used

  实际由此资源使用的 32KB 页面数。

• max

  自节点上次启动以来使用的此资源的最大数量（32KB 页面数）。

注意事项

resource_name可以是以下表中显示的任何一个名称：

• RESERVED：系统保留；不能被覆盖。

• TRANSACTION_MEMORY：为此数据节点上的事务分配的内存。在 NDB 8.0.19 及更高版本中，可以使用TransactionMemory配置参数来控制。

• DISK_OPERATIONS：如果分配了日志文件组，则使用撤销日志缓冲区的大小来设置此资源的大小。此资源仅用于为撤销日志文件组分配撤销日志缓冲区；只能有一个这样的组。根据需要通过CREATE LOGFILE GROUP进行过度分配。

• DISK_RECORDS：为磁盘数据操作分配的记录。

• DATA_MEMORY：用于主内存元组、索引和哈希索引。DataMemory 和 IndexMemory 的总和，如果 IndexMemory 已设置，则再加上 8 个 32KB 的页面。不能过度分配。

• JOBBUFFER：由 NDB 调度程序用于分配作业缓冲区；不能过度分配。每个线程大约为 2MB，以及所有可以通信的线程两个方向各有 1MB 的缓冲区。对于大型配置，这将消耗数 GB。

• FILE_BUFFERS：由DBLQH内核块中的重做日志处理程序使用；不能过度分配。大小为NoOfFragmentLogParts * RedoBuffer，再加上每个日志文件部分 1MB。

• TRANSPORTER_BUFFERS: 由ndbmtd")使用的发送缓冲区；TotalSendBufferMemory和ExtraSendBufferMemory之和。这个资源可以过度分配多达 25%。TotalSendBufferMemory通过对每个节点的发送缓冲区内存求和来计算，其默认值为 2 MB。因此，在一个有四个数据节点和八个 API 节点的系统中，数据节点有 12 * 2 MB 的发送缓冲区内存。ExtraSendBufferMemory由ndbmtd")使用，每个线程额外使用 2 MB 内存。因此，对于 4 个 LDM 线程、2 个 TC 线程、1 个主线程、1 个复制线程和 2 个接收线程，ExtraSendBufferMemory为 10 * 2 MB。可以通过设置SharedGlobalMemory数据节点配置参数来过度分配这个资源。

• DISK_PAGE_BUFFER: 用于磁盘页缓冲区；由DiskPageBufferMemory配置参数确定。不能过度分配。

• QUERY_MEMORY: 被DBSPJ内核块使用。

• SCHEMA_TRANS_MEMORY: 最小为 2 MB；可以过度分配以使用任何剩余的可用内存。

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

25.6.16.52 ndbinfo restart_info 表

restart_info表包含有关节点重新启动操作的信息。表中的每个条目对应于具有给定节点 ID 的数据节点实时的节点重新启动状态报告。仅显示任何给定节点的最新报告。

restart_info表包含以下列：

• node_id

  集群中的节点 ID

• node_restart_status

  节点状态；请参阅文本以获取值。每个值对应于node_restart_status_int的可能值。

• node_restart_status_int

  节点状态代码；请参阅文本以获取值。

• secs_to_complete_node_failure

  完成节点故障处理所需的秒数

• secs_to_allocate_node_id

  从节点故障完成到分配节点 ID 所需的秒数

• secs_to_include_in_heartbeat_protocol

  从分配节点 ID 到包含在心跳协议中所花费的秒数

• secs_until_wait_for_ndbcntr_master

  从包含在心跳协议中到等待NDBCNTR主节点开始等待的秒数

• secs_wait_for_ndbcntr_master

  等待被NDBCNTR主节点接受开始的秒数

• secs_to_get_start_permitted

  从主节点接收启动许可到所有节点接受此节点启动所花费的秒数

• secs_to_wait_for_lcp_for_copy_meta_data

  等待复制元数据之前等待 LCP 完成所花费的秒数

• secs_to_copy_meta_data

  从主节点复制元数据到新开始节点所需的秒数

• secs_to_include_node

  等待 GCP 和所有节点加入协议的秒数

• secs_starting_node_to_request_local_recovery

  刚开始的节点等待请求本地恢复所花费的秒数

• secs_for_local_recovery

  刚开始的节点本地恢复所需的秒数

• secs_restore_fragments

  从 LCP 文件中恢复片段所需的秒数

• secs_undo_disk_data

  执行在磁盘数据部分上的撤销日志所需的秒数

• secs_exec_redo_log

  执行重做日志在所有恢复片段上所需的秒数

• secs_index_rebuild

  重建恢复片段上的索引所需的秒数

• secs_to_synchronize_starting_node

  从活动节点同步开始节点所需的秒数

• secs_wait_lcp_for_restart

  完成重新启动之前开始和完成 LCP 所需的秒数

• secs_wait_subscription_handover

  等待复制元数据的秒数

• total_restart_secs

  从节点故障到节点再次启动的总秒数

备注

以下列表包含了node_restart_status_int列中定义的值及其内部状态名称（括号中），以及在node_restart_status列中显示的相应消息：

• 0 (ALLOCATED_NODE_ID)

  分配的节点 ID

• 1 (INCLUDED_IN_HB_PROTOCOL)

  包含在心跳协议中

• 2 (NDBCNTR_START_WAIT)

  等待 NDBCNTR 主节点允许我们启动

• 3 (NDBCNTR_STARTED)

  NDBCNTR 主节点允许我们启动

• 4 (START_PERMITTED)

  所有节点允许我们启动

• 5 (WAIT_LCP_TO_COPY_DICT)

  等待 LCP 完成以开始复制元数据

• 6 (COPY_DICT_TO_STARTING_NODE)

  正在将元数据复制到起始节点

• 7 (INCLUDE_NODE_IN_LCP_AND_GCP)

  将节点包含在 LCP 和 GCP 协议中

• 8 (LOCAL_RECOVERY_STARTED)

  正在恢复片段

• 9 (COPY_FRAGMENTS_STARTED)

  正在将起始节点与活动节点同步

• 10 (WAIT_LCP_FOR_RESTART)

  等待 LCP 以确保持久性

• 11 (WAIT_SUMA_HANDOVER)

  等待订阅切换

• 12 (RESTART_COMPLETED)

  重启已完成

• 13 (NODE_FAILED)

  节点失败，故障处理正在进行中

• 14 (NODE_FAILURE_COMPLETED)

  节点故障处理已完成

• 15 (NODE_GETTING_PERMIT)

  所有节点允许我们启动

• 16 (NODE_GETTING_INCLUDED)

  将节点包含在 LCP 和 GCP 协议中

• 17 (NODE_GETTING_SYNCHED)

  正在将起始节点与活动节点同步

• 18 (NODE_GETTING_LCP_WAITED)

  [无]

• 19 (NODE_ACTIVE)

  重启已完成

• 20 (NOT_DEFINED_IN_CLUSTER)

  [无]

• 21 (NODE_NOT_RESTARTED_YET)

  初始状态

状态编号 0 到 12 仅适用于主节点；表中显示的其余状态编号适用于所有重新启动的数据节点。状态编号 13 和 14 定义了节点故障状态；20 和 21 发生在没有关于给定节点重新启动的信息时。

另请参阅 Section 25.6.4, “NDB Cluster 启动阶段总结”。

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

25.6.16.53 ndbinfo server_locks 表

server_locks表的结构类似于cluster_locks表，并提供后者中找到的信息的子集，但是特定于 SQL 节点（MySQL 服务器）的信息（cluster_locks表提供有关集群中所有锁的信息）。更确切地说，server_locks包含由属于当前mysqld实例的线程请求的锁的信息，并作为server_operations的伴随表。这可能有助于将锁定模式与特定的 MySQL 用户会话、查询或用例相关联。

server_locks表包含以下列：

• mysql_connection_id

  MySQL 连接 ID

• 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 的锁

备注

mysql_connection_id列显示由SHOW PROCESSLIST显示的 MySQL 连接或线程 ID。

block_instance指的是内核块的一个实例。与块名称一起，此数字可用于在threadblocks表中查找给定实例。

tableid由NDB分配给表；在其他ndbinfo表中以及ndb_show_tables的输出中使用相同的 ID 来表示此表。

transid列中显示的事务 ID 是由 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标识）。

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

25.6.16.54 ndbinfo server_operations 表

server_operations表包含当前 SQL 节点（MySQL 服务器）当前参与的所有进行中的NDB操作的条目。它实际上是cluster_operations表的一个子集，其中不显示其他 SQL 和 API 节点的操作。

server_operations表包含以下列：

• mysql_connection_id

  MySQL 服务器连接 ID

• node_id

  节点 ID

• block_instance

  块实例

• transid

  事务 ID

• operation_type

  操作类型（请参阅文本以获取可能的值）

• state

  操作状态（请参阅文本以获取可能的值）

• tableid

  表 ID

• fragmentid

  片段 ID

• client_node_id

  客户端节点 ID

• client_block_ref

  客户端块引用

• tc_node_id

  事务协调器节点 ID

• tc_block_no

  事务协调器块编号

• tc_block_instance

  事务协调器块实例

备注

mysql_connection_id与SHOW PROCESSLIST输出中显示的连接或会话 ID 相同。它从INFORMATION_SCHEMA表NDB_TRANSID_MYSQL_CONNECTION_MAP中获取。

block_instance指的是内核块的一个实例。与块名称一起，此数字可用于在threadblocks表中查找给定实例。

事务 ID（transid）是一个唯一的 64 位数字，可以使用 NDB API 的getTransactionId()方法获取。（目前，MySQL 服务器不公开正在进行的事务的 NDB API 事务 ID。）

operation_type列可以取以下任一值：READ、READ-SH、READ-EX、INSERT、UPDATE、DELETE、WRITE、UNLOCK、REFRESH、SCAN、SCAN-SH、SCAN-EX或<unknown>。

state列可以具有以下任一值：ABORT_QUEUED、ABORT_STOPPED、COMMITTED、COMMIT_QUEUED、COMMIT_STOPPED、COPY_CLOSE_STOPPED、COPY_FIRST_STOPPED、COPY_STOPPED、COPY_TUPKEY、IDLE、LOG_ABORT_QUEUED、LOG_COMMIT_QUEUED、LOG_COMMIT_QUEUED_WAIT_SIGNAL、LOG_COMMIT_WRITTEN、LOG_COMMIT_WRITTEN_WAIT_SIGNAL、LOG_QUEUED、PREPARED、PREPARED_RECEIVED_COMMIT、SCAN_CHECK_STOPPED、SCAN_CLOSE_STOPPED、SCAN_FIRST_STOPPED、SCAN_RELEASE_STOPPED、SCAN_STATE_USED、SCAN_STOPPED、SCAN_TUPKEY、STOPPED、TC_NOT_CONNECTED、WAIT_ACC、WAIT_ACC_ABORT、WAIT_AI_AFTER_ABORT、WAIT_ATTR、WAIT_SCAN_AI、WAIT_TUP、WAIT_TUPKEYINFO、WAIT_TUP_COMMIT或WAIT_TUP_TO_ABORT。（如果 MySQL 服务器使用ndbinfo_show_hidden启用运行，则可以通过从通常隐藏的ndb$dblqh_tcconnect_state表中选择来查看此状态列表。）

通过检查ndb_show_tables的输出，您可以通过表 ID 获取NDB表的名称。

fragid与ndb_desc的输出中看到的分区号相同，--extra-partition-info（简写为-p）。

在client_node_id和client_block_ref中，client指的是 NDB Cluster API 或 SQL 节点（即，NDB API 客户端或连接到集群的 MySQL 服务器）。

block_instance和tc_block_instance列提供 NDB 内核块实例号。您可以使用这些信息从threadblocks表中获取有关特定线程的信息。