MySQL NDB内存列和磁盘列怎么划分

我在给 NDB 表做容量规划时，最容易误判的一点是：STORAGE DISK 不等于“所有列都不占内存”。NDB 的索引和索引列必须留在内存；磁盘表主要把非索引列放到 Disk Data。实际划分应先看查询是否需要索引，再看列是热数据还是体积较大的冷数据。

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

一、先按索引边界划分，而不是按字段大小硬切

对 NDB 表使用磁盘存储时，真正的第一条规则是索引优先。主键列、唯一索引列和普通索引列要支持定位，因此其列数据仍在内存中；没有索引的列才有机会放到数据文件。也就是说，一个“磁盘表”可以同时拥有内存列和磁盘列。

下面的定义把整张表设为 Disk Data，但 id、tenant_id 和 created_at 因为参与索引，不能按普通非索引列理解：

-- 表级 STORAGE DISK 只改变非索引列的默认归属
CREATE TABLE order_archive (
    id BIGINT NOT NULL PRIMARY KEY,
    tenant_id BIGINT NOT NULL,
    created_at DATETIME NOT NULL,
    payload JSON,
    note TEXT,
    -- 这个索引决定 tenant_id、created_at 仍要支持内存中的索引访问
    KEY idx_tenant_time (tenant_id, created_at)
) TABLESPACE archive_ts
  STORAGE DISK
  ENGINE = NDBCLUSTER;

这里更稳妥的理解是：索引列是内存访问路径的一部分，payload 和 note 这类非索引列才是磁盘空间的主要候选。不要只因为某列很大就把它设成 DISK；如果查询经常按它过滤，先确认建立索引带来的内存代价。

二、最小配方：先建日志组和 tablespace

NDB 的 Disk Data 不是在 CREATE TABLE 里凭空出现的。先创建包含 undo 文件的 log file group，再创建绑定数据文件的 tablespace，最后让表引用这个 tablespace。三者缺一时，磁盘表的 DDL 就没有完整的落点。

-- 第一步：为磁盘表准备事务回滚所需的 undo 文件
CREATE LOGFILE GROUP archive_lg
  ADD UNDOFILE 'archive_undo.log'
  INITIAL_SIZE 128M
  ENGINE = NDBCLUSTER;

-- 第二步：把数据文件和日志组绑定到 tablespace
CREATE TABLESPACE archive_ts
  ADD DATAFILE 'archive_data.dat'
  USE LOGFILE GROUP archive_lg
  INITIAL_SIZE 1G
  ENGINE = NDBCLUSTER;

-- 第三步：表级默认使用磁盘，非索引列按规则进入 Disk Data
CREATE TABLE order_archive (
    id BIGINT NOT NULL PRIMARY KEY,
    payload JSON,
    note TEXT
) TABLESPACE archive_ts
  STORAGE DISK
  ENGINE = NDBCLUSTER;

这段 DDL 是结构示例，容量和文件名要按实际节点规划调整。官方说明中，NDB 的 data file 与 undo log file 会出现在每个数据节点上；因此不能把单个节点上的文件大小误认为整个集群只保存了一份。

三、用列级 STORAGE 把热列拉回内存

表级默认适合“多数列偏冷、少数列用于定位”的归档场景。如果某个非索引列在读路径上非常热，可以显式写 STORAGE MEMORY；反过来，也可以在内存表的明确列上写 STORAGE DISK，但它仍然需要一个 NDB tablespace。

-- 表级给出磁盘默认值，摘要列明确留在内存
CREATE TABLE customer_snapshot (
    customer_id BIGINT NOT NULL PRIMARY KEY,
    status_code SMALLINT STORAGE MEMORY,
    profile_json JSON STORAGE DISK,
    remark VARCHAR(500) STORAGE DISK
) TABLESPACE archive_ts
  STORAGE DISK
  ENGINE = NDBCLUSTER;

-- STORAGE DISK 不能脱离 TABLESPACE 单独使用
-- 内存表也可显式写 STORAGE MEMORY，表达设计意图
CREATE TABLE hot_customer (
    customer_id BIGINT NOT NULL PRIMARY KEY,
    status_code SMALLINT STORAGE MEMORY
) STORAGE MEMORY
  ENGINE = NDBCLUSTER;

我通常把主键、路由键和高频过滤条件看作“访问骨架”，把完整 JSON、长文本和低频描述看作“内容层”。这个分法比单纯按字段类型决定 MEMORY/DISK 更可靠，因为索引变化会改变列的存储约束。

四、三个容易把容量算错的边界

• 磁盘列不是零内存。NDB 每行仍要在内存中保存指向磁盘数据的指针，文档给出的典型开销是 8 字节；很小的列从 MEMORY 改成 DISK，内存占用反而可能变大。
• TEXT 和 BLOB 有内存前缀。Disk Data 表中，这两类列的前 256 字节保留在内存，只有后续部分放在磁盘。
• 变长列按最大可能值规划磁盘空间。Disk Data 的变长列按每行允许的最大值占用固定空间，不能只拿当前平均长度乘行数估算。

最后还要单独看磁盘页缓存和文件空间。可以通过 INFORMATION_SCHEMA.FILES 了解 NDB 文件对象，再结合 DiskPageBufferMemory 和磁盘访问情况调整参数。不要把普通 InnoDB 的表空间经验直接套到 NDB 上。

常见追问

给非索引列加索引后还会留在磁盘吗？

隐式使用磁盘存储的列可以加索引，但加索引后其存储类型会自动转为 MEMORY；显式声明为 STORAGE DISK 的列则要先改回 MEMORY，才能建立索引。

所有不加索引的列都适合放磁盘吗？

不一定。小字段可能因为 8 字节指针增加内存成本，TEXT/BLOB 还有 256 字节前缀；高频读取也可能受到磁盘访问影响，应按访问路径和容量一起判断。