引言

在数据库内核的深处，有一个影响着所有查询性能的根本性设计——表的存储模型。它决定了数据在磁盘上的物理排列方式，是所有索引、查询优化器乃至SQL执行效率的基石。

绝大多数主流数据库，都站在了两种设计哲学的岔路口上：

• 堆表：Oracle（默认）、PostgreSQL、SQL Server
• 索引组织表：MySQL（InnoDB）、达梦（默认）

两者没有绝对的优劣，只有场景的适配。本文将深入剖析这两种存储模型的设计原理、优劣对比，并揭示它们与索引、ROWID之间的深层关系。

---

一、核心概念：什么是堆表？

1.1 定义

堆表是指数据行按插入顺序无序存储的表结构。新插入的行会放在第一个能找到的空闲位置，没有任何排序规则。

“堆”这个名字，形象地描述了数据像一堆货物一样堆放在仓库中——没有顺序，没有结构，只有位置。

1.2 存储结构

堆表的数据块（Block）中，数据行存放在任意可用空间，通过行目录来跟踪每个行的物理位置。

text

数据块 (Block) 结构：
+------------------+
|   块头 (Header)   |
+------------------+
|   行目录 (Row Directory)  | ---- 存储指向各数据行的指针
+------------------+
|   空闲空间         |
+------------------+
|   数据行 1        |
|   数据行 2        |
|   ...             |
+------------------+

1.3 定位机制：ROWID

由于堆表数据无序，必须有一个物理地址来精确定位每一行数据。这就是ROWID——Oracle数据库的核心设计。

ROWID通常包含以下信息：

• 数据对象编号
• 数据文件编号
• 数据块编号
• 行号（块内偏移）

ROWID可以理解为每行数据的GPS坐标，一旦生成，在其生命周期内通常保持不变（除非发生行迁移）。

---

二、核心概念：什么是索引组织表（IOT）？

2.1 定义

索引组织表是指数据表本身就是一棵B+树，数据行按主键顺序存储在B+树的叶子节点中。

一句话概括：表即索引，索引即表。

2.2 存储结构

在索引组织表中，聚簇索引（Clustered Index）就是数据本身：

text

B+树结构（索引组织表）：
           [根节点]
          /   |   \
    [分支]  [分支]  [分支]
    /  |     |  \    |  \
 [叶子] [叶子] [叶子] [叶子] [叶子]
   ↓     ↓     ↓     ↓     ↓
 数据行 数据行 数据行 数据行 数据行 (按主键顺序存储)

• 非叶子节点：存储主键值和指向子节点的指针
• 叶子节点：存储完整的数据行（或数据的指针，取决于具体实现）

2.3 定位机制：逻辑地址

由于数据位置会随着B+树的分裂/合并而变化，索引组织表无法使用固定的物理ROWID。取而代之的是逻辑ROWID或主键值本身。

在MySQL InnoDB中：

• 聚簇索引的叶子节点直接包含所有列数据
• 二级索引的叶子节点存储的是主键值，查询时需要“回表”到聚簇索引

---

三、全方位对比：堆表 vs 索引组织表

对比维度	📦 堆表	🌲 索引组织表 (IOT)
数据存储顺序	无序（插入顺序）	按主键有序
主键索引	独立的B树索引，叶子存ROWID	就是表本身，叶子存完整数据
二级索引内容	(索引列值, ROWID)	(索引列值, 主键值)
数据访问路径	先查索引获取ROWID → 回表取数据	直接在索引上定位，无需回表
ROWID性质	物理地址，稳定	逻辑地址或主键值，可变
插入效率	⚡ 极高（直接追加或找空闲位置）	较慢（需维持主键顺序，可能页分裂）
主键查询效率	较慢（需走主键索引再回表）	🚀 极快（一次定位即可）
范围查询	走索引回表，若需排序代价高	🚀 极快（数据物理有序）
空间利用率	高（无预留空间要求）	稍低（需预留空间减少页分裂）
碎片控制	需要定期重建	B+树自平衡可缓解
典型代表	Oracle、PostgreSQL、SQL Server	MySQL InnoDB、达梦

---

四、工作原理深度解析

4.1 堆表的CRUD操作

SELECT（单行）

sql

SELECT * FROM employees WHERE id = 1001;

1. 在主键索引B树中查找id=1001 → 获得ROWID
2. 根据ROWID直接定位堆表中的数据块
3. 读取完整数据行

INSERT

sql

INSERT INTO employees VALUES (...);

1. 在堆表中找一个有足够空闲空间的数据块
2. 将数据行写入该块的空闲位置
3. 更新该块的行目录
4. 在所有二级索引中插入(索引列值, ROWID)

优势：插入操作几乎没有顺序限制，只需找到空闲位置即可，因此并发写入性能极高。

UPDATE（不更新主键）

sql

UPDATE employees SET salary = 50000 WHERE id = 1001;

1. 通过ROWID定位数据行
2. 原地修改（如果新行长度小于等于旧行）
3. 或行迁移（如果超长，搬到新位置，原位置留指针）

4.2 索引组织表的CRUD操作

SELECT（单行）

sql

SELECT * FROM employees WHERE id = 1001;

1. 从B+树根节点开始
2. 沿树向下查找id=1001
3. 到达叶子节点 → 直接读取完整数据行

优势：全程只需一次B树遍历，无需额外的回表操作，主键查询极快。

INSERT

sql

INSERT INTO employees VALUES (...);

1. 根据主键值定位应插入的叶子节点位置
2. 如果该页未满 → 插入并保持有序
3. 如果该页已满 → 页分裂（分配新页，移动约一半数据）
4. 更新分支节点和根节点
5. 更新二级索引（存储(索引列值, 主键值)）

代价：如果主键是随机值（如UUID），每次插入都可能引起页分裂，严重降低写入性能。

---

五、关键差异：回表与二级索引

5.1 堆表的回表

在堆表中，二级索引的访问路径是：

text

二级索引 → 获取ROWID → 直接定位数据（一次I/O）

由于ROWID是物理地址，回表操作非常高效，可以理解为“点对点直达”。

5.2 索引组织表的回表

在索引组织表中，二级索引的访问路径是：

text

二级索引 → 获取主键值 → 搜索聚簇索引 → 定位数据（最多两次I/O）

虽然多了一次B树查找，但由于聚簇索引的B树通常高度较低（2-4层），额外开销也相对可控。

5.3 覆盖索引的差异

覆盖索引是指查询所需的所有列都在索引中，无需访问数据表本身。

场景	堆表	索引组织表
覆盖索引	完全不需要回表，二级索引即可满足	完全不需要回表，二级索引即可满足
非覆盖查询	需要一次回表（通过ROWID）	需要一次回表（通过主键值）

两者在覆盖索引优化上没有本质区别，只是回表的具体实现机制不同。

---

六、实战选择指南

6.1 何时选择堆表？

✅ 高并发写入场景

• 日志系统、流水记录、事件溯源
• 主键为序列号或时间戳，但不需要物理顺序

✅ 二级索引丰富

• 表上有多个二级索引，且索引列选择性不高
• 堆表的二级索引统一存储ROWID，访问路径一致

✅ 需要频繁更新非索引列

• 堆表数据行可在原地修改（除非行迁移）
• 索引组织表可能因主键更新（不推荐）或页分裂导致移动

✅ 典型代表

• Oracle、PostgreSQL、SQL Server用户，无需改变习惯
• 数据仓库、报表系统（配合分区表）

6.2 何时选择索引组织表？

✅ 主键查询为主

• 用户表（按用户ID查）、订单表（按订单ID查）
• 一次B树查找即可获得全部数据

✅ 主键范围查询

• 时间范围查询（时间戳为主键或前导列）
• 数据物理有序，范围扫描效率极高

✅ 主键本身就是查询关键

• 关联查询中的主键-外键关系
• 避免额外的回表开销

✅ 典型代表

• MySQL用户（InnoDB是唯一选择）
• 达梦用户（默认就是索引组织表）
• 对主键查询性能有极致要求

---

七、数据库阵营速览

数据库	默认存储模型	是否支持另一种	备注
Oracle	堆表	✅ 支持IOT（需显式指定ORGANIZATION INDEX）	两种都支持，灵活选择
达梦	索引组织表	✅ 支持堆表	完全兼容Oracle语法，可按需选择
MySQL	索引组织表	❌ 不支持堆表	InnoDB强制使用聚簇索引
PostgreSQL	堆表	❌ 不支持IOT	可通过插件或分区表模拟
SQL Server	堆表	✅ 支持聚集索引	建聚集索引后即变成索引组织表

---

八、性能案例：哪个更快？

场景1：单主键查询

sql

SELECT * FROM users WHERE id BETWEEN 1 AND 1000;

• 索引组织表：数据物理有序，范围扫描极快，一次B树遍历即可获取所有数据
• 堆表：需查找主键索引，获取1000个ROWID，再逐个回表（随机I/O）
• 结论：✅ 索引组织表胜出

场景2：大量随机插入

sql

INSERT INTO events (uuid, data) VALUES (UUID(), ...);  -- 每秒10000次

• 索引组织表：主键随机，每次插入都可能导致页分裂，写入性能急剧下降
• 堆表：数据追加到末尾或空闲位置，几乎无顺序要求，并发写入性能极高
• 结论：✅ 堆表胜出

场景3：二级索引查询

sql

SELECT * FROM orders WHERE status = 'PAID' AND create_time > '2024-01-01';

• 堆表：二级索引存储ROWID，查到后可直接定位，回表路径短
• 索引组织表：二级索引存储主键值，需要两次B树查找
• 结论：⚖️ 差异不大，堆表略优（回表更直接），但IOT可通过覆盖索引优化

---

九、总结：没有银弹，只有权衡

堆表和索引组织表代表了两种不同的设计哲学：

• 堆表：追求写入性能和存储灵活性，通过独立的B树索引和ROWID实现高效查询，是Oracle、PostgreSQL等成熟数据库的经典选择。
• 索引组织表：追求主键查询的极致性能，通过B+树将索引和数据合二为一，是MySQL InnoDB和达梦的核心设计。

选择建议：

• 如果你的业务以主键查询和范围扫描为主，写入相对平稳 → 优先考虑索引组织表
• 如果你的系统有海量并发写入、主键随机性强、二级索引较多 → 优先考虑堆表
• 如果你使用Oracle或达梦，甚至可以混合使用：核心业务表用堆表，特殊需求表用IOT

达梦社区技术 https://eco.dameng.com