MySQL NDB Disk Data的表空间和日志文件组有什么关系

在 MySQL NDB Cluster 的 Disk Data 里，表空间和日志文件组不是同一个东西：表空间是组织数据文件的容器，日志文件组则组织一个或多个撤销日志文件，并被表空间引用。换句话说，数据文件回答“列数据放在哪里”，撤销日志文件回答“事务回滚信息放在哪里”，表空间把这两类资源关联到同一个 Disk Data 存储边界。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/mysql-cluster-disk-data-objects.html

这个关系只适用于 NDB Cluster 的 Disk Data。NDB 官方手册还规定，同一个集群当前最多只能有一个日志文件组，因此不能把它理解成 InnoDB 那种可以随意创建多个独立 undo 表空间的模型。

先画清表空间和日志文件组的关系

因此，依赖关系可以压缩成一句话：表空间 -> 数据文件，同时 表空间 -> 日志文件组 -> 撤销日志文件。表空间负责承接数据文件，日志文件组负责提供撤销日志组织方式；两者通过 USE LOGFILE GROUP 连接。

按依赖顺序创建对象

创建 Disk Data 表时，先有日志文件组，再有引用它的表空间，最后才是使用该表空间的表。日志文件组至少要带一个撤销日志文件；表空间创建时则要指定日志文件组和至少一个数据文件。

-- 先建立撤销日志组织，并加入第一个撤销日志文件
CREATE LOGFILE GROUP lg_orders
  ADD UNDOFILE 'undo_orders.log'
  INITIAL_SIZE 64M
  UNDO_BUFFER_SIZE 8M
  ENGINE NDBCLUSTER;

-- 再创建数据容器，并把它绑定到日志文件组
CREATE TABLESPACE ts_orders
  ADD DATAFILE 'orders.dat'
  USE LOGFILE GROUP lg_orders
  INITIAL_SIZE 256M
  ENGINE NDBCLUSTER;

-- 最后让 Disk Data 表使用这个表空间
CREATE TABLE orders_history (
  order_id BIGINT UNSIGNED NOT NULL,
  created_at DATETIME NOT NULL,
  payload VARBINARY(512) STORAGE DISK,
  PRIMARY KEY (order_id)
) TABLESPACE ts_orders
  STORAGE DISK
  ENGINE NDBCLUSTER;

这里的 lg_orders 不是数据文件名，而是一个逻辑的日志文件组对象；undo_orders.log 才是实际创建的撤销日志文件。类似地，ts_orders 是表空间对象，orders.dat 才是实际数据文件。扩容时可以通过 ALTER TABLESPACE ... ADD DATAFILE 增加数据文件，但仍然是在同一个表空间边界内管理。

如果把这几个名称混用，排查时会出现典型误判：看到磁盘上有 orders.dat，就以为它代表整个表空间；或者看到 undo_orders.log，就以为它可以直接被表绑定。真正被表引用的是表空间，表空间再关联日志文件组。

区分元数据对象和数据节点上的实际文件

MySQL 8.4 手册明确说明，表空间和日志文件组不是文件；数据文件和撤销日志文件才是数据节点文件系统中的实体。添加一个数据文件或撤销日志文件时，NDB 会在集群每个数据节点上创建对应文件。文件的默认位置与数据节点的 DataDir 和 ndb__fs 目录有关，也可以在语句里指定路径。

这解释了为什么“表空间存在”不等于“每台数据节点都有足够磁盘”：表空间是集群对象，而实际容量要落到每个数据节点的文件上。规划容量时要同时看数据文件、撤销日志文件和各节点的磁盘布局。

用 INFORMATION_SCHEMA.FILES 看清归属

不需要通过文件名猜测对象关系，可以查询 INFORMATION_SCHEMA.FILES。对 NDB 来说，FILE_TYPE 会区分 DATAFILE 和 UNDO LOG，TABLESPACE_NAME 表示关联的表空间，LOGFILE_GROUP_NAME 表示所属日志文件组。

-- 用官方元数据列区分数据文件与撤销日志文件
SELECT
  FILE_NAME,
  FILE_TYPE,
  TABLESPACE_NAME,
  LOGFILE_GROUP_NAME,
  FREE_EXTENTS,
  TOTAL_EXTENTS
FROM INFORMATION_SCHEMA.FILES
WHERE ENGINE = 'ndbcluster';

阅读结果时可以按三列判断：FILE_TYPE = DATAFILE 的行是表空间的数据文件；FILE_TYPE = UNDO LOG 的行是撤销日志文件；LOGFILE_GROUP_NAME 则把两类文件放回同一个日志文件组关系中。MySQL 8.4 还会以相对路径展示 NDB 文件名，数据文件和撤销日志文件分别对应数据节点文件系统下的不同目录。

架构取舍和删除边界

这个设计的核心取舍是把“数据容量”和“事务回滚资源”分成两层管理：数据文件可以在表空间内扩展，撤销日志文件由日志文件组统一组织，但表空间必须引用一个现有的日志文件组。这样做让表空间成为表的数据落点，也让事务恢复资源有明确归属。

删除时依赖关系反过来：不能在仍有表使用时删除数据文件；表空间还有数据文件时不能删除表空间；仍被表空间使用时不能删除日志文件组。实际变更前应先解除表和文件的依赖，再按对象层级清理，避免把逻辑对象和物理文件的生命周期混在一起。

• 只想定位列数据容量：先看表空间和 DATAFILE 行。
• 只想定位回滚资源：看日志文件组和 UNDO LOG 行。
• 发现单节点磁盘异常：不要只看集群级对象名，要逐个数据节点检查对应文件。
• 准备删除或迁移：先确认表、数据文件、表空间、日志文件组的依赖顺序。

常见问题

表空间是不是一个实际的目录或文件？

不是。表空间是 NDB 的逻辑容器，实际落盘的是它包含的数据文件；日志文件组同样是逻辑对象，实际落盘的是它管理的撤销日志文件。

一个表空间能不能不指定日志文件组？

不能。创建 NDB Disk Data 表空间时需要指定用于撤销日志的日志文件组，并且日志文件组必须先存在并包含撤销日志文件。

为什么 FILES 表里同一个文件关系看起来分散？

NDB 会在每个数据节点保存数据文件和撤销日志文件的副本，FILES 表按文件提供记录。应结合 FILE_TYPE、TABLESPACE_NAME 和 LOGFILE_GROUP_NAME 读取，不要只按文件名判断。