【数据库研究前沿】CXL 3.0 与内存池化：对缓冲池与共享内存模型的重塑

这是【数据库研究前沿】系列的第 16 篇。上一篇 共享内存事务 讨论了 FaRM、Sundial 这类”用 RDMA / 共享内存重写分布式事务”的工作。这一篇把镜头从机柜间的 RDMA 往前移半步，聚焦在一个更具体的硬件趋势：Compute Express Link（CXL）——它不是一种新的网络，而是一种让 CPU 把远端内存当成本地内存挂载的总线协议。

对数据库工程师来说，CXL 引发的真正问题只有一个：如果”一块内存”的访问延迟变成一个分布在 80 ns – 400 ns 之间的谱系，而不是一个单点，那么 buffer pool、shared_buffers、InnoDB LRU 这些已经写了二十年的代码，应该怎么改？

本文分两半。上半（约 60%）梳理 CXL 1.1 / 2.0 / 3.0 的演进路径、Type 1/2/3 设备的区分、两篇关键云内存池化论文（Meta 的 TPP、Microsoft 的 Pond）给出的延迟与收益数据，以及这些对 DBMS buffer pool 设计假设的冲击。下半（约 40%）落到 PostgreSQL 与 MySQL 的调参方向、当前开源实验项目的现状，以及哪些路径”能动”、哪些还要再等两年。

版本说明 本文以 CXL 3.0 Specification（2022 年 8 月发布）、CXL 3.1（2023 年 11 月）为主要参考，硬件以 Intel Sapphire Rapids / Emerald Rapids、AMD Genoa / Turin 支持的 CXL 1.1 / 2.0 为基线。PostgreSQL 17、MySQL 8.4 为调参参考版本。所有延迟数字仅针对 2023–2025 年期间公开披露的原型或早期产品，后续产品可能变化。

一、CXL 是什么：把 PCIe 升级成”缓存一致总线”

1.1 从 PCIe 到 CXL

传统的 PCIe（Peripheral Component Interconnect Express）解决的是”CPU 和设备之间传数据”的问题：NVMe SSD、GPU、网卡都挂在 PCIe 上，设备拥有自己的 DRAM 和地址空间，CPU 需要通过 DMA 或 MMIO 显式搬运数据。这种模型的核心限制是：设备内存不在 CPU 的缓存一致性域里，CPU 看不到设备修改内存、设备也看不到 CPU 的缓存。

CXL（Compute Express Link）的出发点是在 PCIe 的物理层之上，叠一层”可以参与 CPU 缓存一致性协议”的逻辑层。一个 CXL 链路上同时跑三个子协议：

• CXL.io：等价于 PCIe，负责设备发现、中断、配置空间；
• CXL.cache：允许设备像另一个 CPU 核心那样，把主机内存拉到自己的缓存里（并参与 MESI 协议）；
• CXL.mem：允许 CPU 把设备的 DRAM 当作自己的系统内存访问，load / store 指令直接发出，不需要 DMA。

这三个子协议的组合决定了设备的”CXL 类型”，也直接决定了数据库能做什么。

1.2 Type 1 / 2 / 3：只记住一张表就够

CXL 规范里把设备分成三类：

数据库场景里关注的几乎全是 Type 3：一块插在 PCIe 插槽上的板卡，板卡上挂着一排 DDR5 DIMM，通过 CXL.mem 暴露给 CPU。操作系统把这块内存识别成一个 NUMA 节点，和本地 DRAM 一样可以 mmap、可以做 buffer pool。

1.3 CXL 1.1 → 2.0 → 3.0：从”扩展卡”到”内存结构”

三代规范解决的是不同范围的问题：

• CXL 1.1（2019）：单主机、点对点。一台服务器挂一块 CXL 内存卡，只自己用。主要价值是”绕过 DDR 插槽上限”。
• CXL 2.0（2020）：引入 CXL Switch，允许 N 台主机共享 M 块 CXL 内存，支持”内存池（Memory Pool）“语义。但同一块内存区域同一时刻只能由一台主机独占（通过分配/回收切换）。
• CXL 3.0（2022）：真正的”fabric”。支持多级 switch、多主机对同一区域的硬件一致性共享（Hardware-Coherent Sharing）、点对点 DMA、64 GT/s PCIe 6.0 物理层。CXL 3.1 进一步补了可信执行（TSP）与 Fabric Manager API。

对数据库而言，CXL 1.1 / 2.0 的价值是”更便宜的大内存”，而 CXL 3.0 的价值是”多个 compute 节点直接共享一段内存”——后者才是能重塑 shared-memory 数据库模型的那一跳。

有一点容易被忽略：CXL 的物理层就是 PCIe 的物理层。这意味着你不需要换主板、不需要换交换机，只要 CPU 支持（Intel Sapphire Rapids 以后、AMD Genoa 以后），现有 PCIe 5.0 插槽就可以跑 CXL 1.1 / 2.0 设备。这是它和”新介质”（例如 Optane DCPMM 要占 DIMM 插槽）最大的经济性差异——CXL 走的是 PCIe 的量产曲线。

1.4 延迟分布：不是一个数字，是一条曲线

谈 CXL 不能只说”远端内存”。真实的延迟谱大致是：

有几个数字必须记住：CXL 1.1 直连 ≈ 一次跨 NUMA 访问的 2 倍，CXL 2.0 一跳 ≈ 3 倍。这意味着 CXL 远端内存并不是”SSD 和内存之间的新层”，而是”本地 DRAM 的稍慢兄弟”——它属于”内存层级（Tier）“,不属于”存储层级”。这是理解后文所有讨论的关键前提。

一个容易被误解的细节：延迟分布不是均匀的。CXL 内存的带宽与本地 DRAM 接近，但延迟的尾部（P99）会显著更重：控制器内部的重排序队列、Switch 的调度、Credit-based 流控，任何一环排队都会被抖动放大。实际测量（例如 Samsung 的 CMM-D 测试报告、Astera Labs 白皮书）显示 CXL 访问的 P50 和 P99 差距可以达到 1.5×–2×，而本地 DRAM 几乎是刚性值。数据库对尾延迟敏感的场景（撮合系统、查询网关、同步复制的 leader）必须把这点纳入考量。

1.5 带宽 vs 延迟：别只看 load-to-use

一块 CXL 1.1 x16 的理论带宽约 64 GB/s（单向），比 DDR5-4800 单通道（约 38 GB/s）宽、比六通道 DDR5（约 230 GB/s）窄。对内存密集型 OLAP 查询（例如 TPC-H 的 Hash Join、Vectorized Aggregate），带宽可能比延迟更关键。CXL 在带宽维度反而不是短板——瓶颈通常是 PCIe 插槽数量，而不是单插槽速率。

从带宽角度看，四插槽全插 CXL 扩展卡的大内存 OLAP 服务器是一个值得关注的拓扑：总带宽可超过 200 GB/s，总容量可过 4 TB。这正是 Snowflake、ClickHouse 这类”单机 OLAP”架构可能最早受益的形态。

二、两篇 ASPLOS 2023 论文：Pond 与 TPP

云厂商是最早部署 CXL 的客群——他们的动机不是 DBMS，而是”数据中心里 20%–40% 的 DRAM 一直闲置”。两篇几乎同时发表的 ASPLOS 2023 论文把这件事量化了。

2.1 Pond：Microsoft Azure 的全机柜内存池

Microsoft 的 Pond（Pond: CXL-Based Memory Pooling Systems for Cloud Platforms, ASPLOS 2023）统计了 Azure 生产机群的内存利用率，发现：

• 大约 25% 的 DRAM 在 50% 的时间里是空闲的；
• 典型 VM 的 working set 远小于分配到的内存，碎片主要来自调度装箱失败；
• 如果能把 8–16 台主机的一部分 DRAM 拉到一个共享池，总体可节省 7%–9% 的 DRAM 成本——在百万级服务器规模下是可观的数字。

Pond 的架构是 CXL 2.0：每台主机保留一部分本地 DRAM（“zNUMA”，zero-core NUMA 节点），剩下的通过 CXL switch 接到共享池。论文的核心贡献不是硬件，而是：

1. 分配策略：用机器学习预测每个 VM 的 working set，把”肯定用不到的那一部分”分到池里；
2. 延迟隐藏：对延迟敏感负载，尽量把分配留在本地；
3. SLA 对齐：论文给出了对 158 个云工作负载的实测，发现将冷内存放在 CXL 池中对 P99 延迟的影响绝大多数在 1%–5% 内。

Pond 对数据库工程师的启发：不是所有内存都值得放在 CXL 上，热点识别必须在 page / object 粒度做。

2.2 TPP：Meta 的 Linux Tiered Memory

Meta 的 TPP（TPP: Transparent Page Placement for CPU-Less NUMA Memory, ASPLOS 2023）走的是另一条路——不假设 CXL 2.0 switch 存在，只把 CXL Type 3 扩展卡当成一个”没有 CPU 的 NUMA 节点”，在 Linux 内核里把冷热页主动迁移。

TPP 的关键设计：

• 解耦回收与晋升：Linux 原生的 LRU 把冷页踢到 swap，TPP 把冷页踢到 CXL 节点；同时有独立的”访问位扫描”线程把 CXL 上重新变热的页拉回本地 DRAM；
• 页粒度（4KB）而非对象粒度：由操作系统透明完成，应用不需要改；
• 实测数据：在 Meta 的 web、cache、graph 三类工作负载上，允许把 20%–25% 的 DRAM 替换为 CXL，端到端性能损失 0.5%–3.5%。

TPP 已经上游到了 Linux 内核（mainline 从 5.18 起逐步支持；numactl 和 mbind 提供 API）。现在任何一台装了 CXL Type 3 设备的机器，只要跑足够新的内核，就能用上这套”透明冷页迁移”。

2.4 补充：一个定量视角

Pond 和 TPP 的结合，能省多少钱、多少能耗？用一个粗略模型估算：

• 一个 1000 台机器的集群，每台 512 GB DRAM，总 DRAM 成本假设 500 万美元；
• Pond 把 10% 的本地 DRAM 替换为池化 CXL 内存：池化溢价 1.2×，但利用率提升至 0.9（单机平均 0.65），等效节省 8%；
• TPP 把本地 25% 替换为 CXL Type 3：Type 3 每 GB 价格约为 DRAM 的 0.8×，总 DRAM 成本降低约 5%；
• 两者叠加：总 DRAM 成本下降 12%–15%。

对单个 1000 台机器的集群，一年节省 60–75 万美元。对 10 万台规模的超大型数据中心，年节省达千万美元量级。这就是云厂商愿意推 CXL 的商业根本。

数据库工程师看这组数字的方式：CXL 的红利首先是云厂商的、其次是多租户大型系统的、最后才是单实例生产库的。如果你是自建 IDC + 自托管 MySQL 的中型公司，CXL 在 2026 年可能还没到落地时点；如果你是云数据库厂商或大型内部平台方，现在是做储备和原型的阶段。

2.5 两种思路的张力

Pond 代表”从云的角度看内存”：跨主机池化，优化装箱；TPP 代表”从单机的角度看内存”：单机分层，优化冷热。两者不冲突，未来大概率会在同一个机柜里同时存在：每台主机先在本地做 TPP，然后机柜级再做 Pond。

对数据库来说，TPP 的冷热迁移机制是”免费的”——操作系统替你做了。而 Pond 级别的池化则需要运维和数据库都介入（后面第四节详述）。

三、CXL 对 DBMS Buffer Pool 假设的冲击

3.1 Buffer Pool 原本的三个隐含假设

PostgreSQL 的 shared_buffers、MySQL InnoDB 的 buffer pool、Oracle 的 db_cache_size，这些名字不同的东西本质上是同一个对象：一块由 DBMS 自己管理、把磁盘页缓存在内存里的 LRU / clock 结构。过去二十年，这个结构的设计建立在三个隐含假设上：

1. 内存是均匀的：每一次访问延迟相同，LRU 的”命中 vs miss”是二元事件；
2. miss 的代价远大于命中：磁盘访问比内存访问慢 10⁴ – 10⁵ 倍，所以命中率是唯一关键指标；
3. 内存容量有刚性上限：插槽数 × DIMM 容量，不可能临时扩容。

CXL 把这三个假设全部松动了：

1. 内存不再均匀：本地 100 ns、CXL 1.1 250 ns、CXL 2.0 400 ns，LRU 变成”命中本地 / 命中远端 / miss 磁盘”三元事件；
2. miss 的代价梯度被拉平：CXL 远端（400 ns）对 SSD（30 μs）仍有 75× 差距，但比起”DRAM vs SSD”的三万倍差距，远端内存访问基本可以视为”略贵的命中”而不是”便宜的 miss”；
3. 内存容量变成弹性：运维可以在不重启主机的情况下，从池里切一块给你——前提是 CXL 2.0 / 3.0 部署到位。

3.2 一个定量直觉：TPC-C 负载下的收益估算

考虑一个 64 GB working set、shared_buffers 设为 32 GB 的 PostgreSQL 实例：

• 基线：命中率 70%，miss 走 NVMe（~50 μs），未命中放大后的平均访问延迟 ≈ 0.7 × 100 ns + 0.3 × 50 000 ns ≈ 15 μs；
• 扩到 64 GB 本地 DRAM：命中率 99%，平均 ≈ 0.99 × 100 + 0.01 × 50 000 ≈ 600 ns——性能大幅提升，但需要更换 DIMM、可能换主板；
• 扩到 64 GB（32 GB 本地 + 32 GB CXL 1.1）：命中率 99%，其中本地命中 70%、CXL 命中 29%，平均 ≈ 0.70 × 100 + 0.29 × 250 + 0.01 × 50 000 ≈ 640 ns；
• 扩到 64 GB 全 CXL 2.0：命中率 99%，平均 ≈ 0.99 × 400 + 0.01 × 50 000 ≈ 900 ns。

几点观察：把一部分 buffer pool 迁到 CXL 是性价比最高的路径——比”全留本地但不够大”快一个数量级，比”全迁 CXL”只慢 50%，但可以免除 DIMM 插槽的物理限制。

3.3 写入放大的隐蔽问题

过滤、聚合这类读操作在 CXL 上收益明确，但写密集负载在 CXL 上反而危险。原因有两个：

1. CXL.mem 协议里的一次 64 字节 store，对应的是一次 PCIe 事务。如果写入区域在 CXL 上，脏行刷回 CXL 节点的延迟是本地的 2–4 倍。对 OLTP 的热点行更新（例如 TPC-C 的 warehouse 表），这个差距会直接体现在事务吞吐上；
2. WAL 的 group commit 依赖”把 buffer 刷到持久存储”的 barrier。如果 WAL buffer 落在 CXL 易失内存上，fsync 之前先要经过一次跨节点拷贝，浪费一个半周期的延迟。

一般建议：CXL 上放只读的冷数据、不可变索引的一部分、或 LRU 中后段；不要放 WAL buffer、log buffer、锁表这种高频写入结构。

3.4 Clock / LRU 算法的失效？

更尖锐的问题是：现有的 LRU / clock 算法是不是”CXL-aware”的？

短答：不是，但影响有限。原生 LRU 只关心”最近访问时间”，不关心”这页现在在本地还是远端”。在 TPP 模式下，这没有问题——OS 会根据访问频率把热页迁回本地，DBMS 无需感知。但在两种情况下 LRU 会明显次优：

1. 访问分布偏态极强：20% 的页占 80% 的访问，但这 20% 能否全部留在本地 DRAM 取决于 shared_buffers 的 CXL / local 比例；
2. 批量扫描污染：全表扫描会把大量”只用一次”的页刷进 LRU，挤掉真正的热页。PostgreSQL 的 ring buffer（用于 seq scan）本来就缓解了这一点，但在分层内存下，让扫描页直接落在 CXL 层是更好的策略——目前没有任何开源数据库实现这一点。

从 ASPLOS / SIGMOD 2024–2025 的论文趋势看，“Tiered-Buffer-Pool”是一个明确在形成的研究方向，但还没有稳定的工业实现。这是”开放问题”。

四、PostgreSQL 与 MySQL 在分层内存下的调参

现在把话题往下拉。假设你面前已经有一台 CXL 1.1 / 2.0 的服务器（例如 Intel Emerald Rapids + Astera Labs Leo CXL 内存扩展），Linux 识别到了两个 NUMA 节点（本地 DRAM 是 node 0，CXL 内存是 node 1），你要跑 PostgreSQL 或 MySQL，具体能做什么。

4.1 路径 A：交给 TPP（最低改动）

这是最省事的路径。步骤：

# 1. 确认内核支持 numa balancing 和 demotion（Linux 5.18+）
cat /proc/sys/kernel/numa_balancing   # 应为 1 或 2
cat /sys/kernel/mm/numa/demotion_enabled   # 应为 true

# 2. 把 CXL 节点设为"可以被降级的目标"
echo true > /sys/kernel/mm/numa/demotion_enabled

# 3. 正常启动 PostgreSQL，不指定 numactl
sudo -u postgres pg_ctl start

原理：PostgreSQL 的 shared_buffers 会按访问局部性自然落在本地 DRAM，冷页被内核降级到 CXL 节点，热页被提升回来。OLTP 负载下，实测（基于厂商样机）TPC-C 吞吐下降通常在 3%–8%，但内存容量翻倍。

适用场景：working set 远大于本地 DRAM、但访问具有明显热点的负载。

不适用：访问均匀（例如 hash join 大表）、或延迟极敏感（金融撮合）。

4.2 路径 B：显式绑定 shared_buffers

更主动的做法是把 PostgreSQL 的 shared_buffers 明确分到两个节点：

# 把 shared_buffers 的 80% 放本地，20% 放 CXL
# 注意：PostgreSQL 没有原生的"分段绑定"参数，需要外部工具
numactl --interleave=0,1 --weight=0:4,1:1 postgres

numactl 的 weighted interleave（Linux 6.9+）是一个相对新的功能，允许按权重分配，而不是严格 round-robin。对 OLAP 类负载（大量连接、内存分配均匀）效果较好。

MySQL InnoDB 提供了更细粒度的 innodb_buffer_pool_instances：将 buffer pool 切成 N 个实例，每个实例可以绑定到不同 NUMA 节点（需要借助 numactl 包装）：

# InnoDB buffer pool 64 GB，切成 8 个实例
# 实例 0–5 在 node 0（本地），实例 6–7 在 node 1（CXL）
# 注意：MySQL 本身不支持"每个实例单独 numa 绑定"，
# 这通常需要修改启动脚本或通过 cgroup 实现

开放问题：MySQL 目前并不支持”按 buffer pool 实例分配 NUMA 节点”。社区有相关讨论和补丁（待核实是否合入），但 2025 年前还未稳定。

4.3 路径 C：Huge Page 与 CXL 的配合

CXL 的 TLB miss 代价相对较高（远端访问本来就慢，再加一次页表 walk 会放大效应）。实际部署中强烈建议：

# 预留 2 MB huge pages 覆盖 shared_buffers 大小
echo 16384 > /proc/sys/vm/nr_hugepages  # 32 GB

# PostgreSQL 启用 huge page
# postgresql.conf:
huge_pages = on

这一条在纯本地 DRAM 上本来就是建议做法，但在分层内存下更为关键。实测 2 MB huge page 可以把 CXL 命中访问的平均延迟降低 10%–20%（主要是减少 TLB miss）。

4.4 路径 D：DBMS 感知的冷热分层（需要代码改动）

上面三条路径都是”外部配置”，最激进的路径是改 DBMS 自己。几种可行的改动点：

PostgreSQL 侧

• 在 BufferTag 结构里新增一个 tier_hint 字段；
• StrategyGetBuffer（clock sweep）替换为两级 clock：一级在本地页中扫，一级在 CXL 页中扫；
• 新增一个后台线程 bgtier，类比 bgwriter，负责”把冷本地页迁到 CXL、把热 CXL 页迁回本地”——这和 Linux 的 TPP 是同样语义，但在 DBMS 层做可以跳过 4KB 粒度限制，按 page（8KB）迁移。

社区尚无正式 patch（2026 年初），CMU 的 DB Group 和 ETH Zürich 有相关研究原型（待核实具体论文）。

MySQL InnoDB 侧

InnoDB 原本就支持 NUMA 感知的 innodb_numa_interleave，扩展到 CXL 的思路类似：

• 把 buffer pool 的 chunk 按 NUMA 节点分组；
• LRU 的 midpoint insertion 策略（young / old sublist）本来就是两段式设计，可以自然对应到”本地 young / CXL old”。

具体补丁也在 Percona、MariaDB 社区讨论中（2024–2025），尚未进 upstream。

4.5 监控：把”CXL 命中率”纳入指标板

CXL-aware 的 DBMS 调优必须有可观测性。最低限度要采集：

• 每个 NUMA 节点的 numa_hit / numa_miss（/sys/devices/system/node/node*/numastat）；
• 每进程的 pagemap 分布（可以用 /proc/$PID/numa_maps 或 numatop 采样）；
• CPU perf 事件 mem_load_retired.l3_miss 中，定位到 CXL 节点的比例（需要 PEBS 采样）。

这些指标应该和 PostgreSQL 的 pg_stat_database.blks_hit / blks_read 一起出现在同一张 Grafana 面板上。没有这套监控，分层内存调优基本是盲调。

4.6 一个具体例子：一台 2 TB 内存的 PostgreSQL

假设硬件：2 socket Sapphire Rapids，本地 DRAM 1 TB（32 × 32 GB DDR5-4800），CXL 扩展 1 TB（2 块 Astera Leo CXL 卡，每卡 512 GB）。Linux 6.9+。工作集大约 800 GB，读写比 9:1。

可行的配置（示意）：

# postgresql.conf
shared_buffers = 768GB
effective_cache_size = 1800GB
huge_pages = on
work_mem = 256MB
maintenance_work_mem = 4GB

# 操作系统层
vm.nr_hugepages = 393216      # 768 GB / 2 MB
kernel.numa_balancing = 2
kernel.sched_migration_cost_ns = 5000000
/sys/kernel/mm/numa/demotion_enabled = true

启动：

# 把 postgres 主进程绑定在 node 0，让 TPP 负责冷热迁移
numactl --cpubind=0 --membind=0,1 --weight=0:3,1:1 \
    /usr/pgsql-17/bin/postgres -D /data/pg17

这样配置下，实测（厂商样机、TPC-C 变种工作负载）相比”只有本地 1 TB”的配置，吞吐接近、P99 略升 5%–8%，但工作集全部驻留，彻底消除了磁盘 miss。这是一个对”时延不极致敏感、但容量需求大”场景的典型解。

五、开源项目现状：哪些能用，哪些还要再等

5.1 已经能用的

5.2 实验性 / 开放问题

• CXL-aware buffer pool：2024–2025 年 SIGMOD / VLDB 有若干原型（MIT、CMU 方向），核心思路是把 page frame header 加一个”层级字段”，替换 clock 算法为”两级 clock”。尚无稳定开源实现。
• 跨主机共享 CXL 3.0 buffer pool：理论上可以让多个 PostgreSQL 实例共享同一个 buffer pool，对 HTAP 极有吸引力。但 CXL 3.0 硬件仍在早期样机阶段（2025 年），数据库侧的协议（一致性粒度、权限控制、崩溃恢复）也几乎没有定论。这是”开放问题”，大概率 2027 年前不会进入生产。
• 向量索引 + CXL：HNSW、IVF-PQ 的图 / 码本天然适合放在 CXL 层（只读多、访问有局部性、容量需求大），参见 向量索引。具体来说，HNSW 的 base layer 图数据每向量约需 1–2 KB 存储，10 亿向量规模约 1–2 TB，单机本地 DRAM 难以容纳，而对 CXL 延迟相对不敏感（图遍历本身是内存访问受限但访问步长少、具有数据局部性）。2024 年 Meta 发表过相关的”分层向量索引”探索（待核实具体论文标题），Milvus 社区也在讨论 CXL-aware 的索引放置策略。

此外还有两类值得关注的新思路：列存中间结果的溢出目标 以及 共享字典（dictionary）的广播。前者指 DuckDB / ClickHouse 在 hash build、sort merge 等操作中超出内存时可以溢出到 CXL 节点而非磁盘；后者指在 OLAP 多租户场景，字典编码（dictionary encoding）的字典可以放在 CXL 共享区域，被多个 compute 节点共用。两者在 2026 年都处于学术探索阶段，但工程难度低于”CXL-aware buffer pool”，更可能先落地。

5.3 一个现实的判断

CXL 在 2025 年的真实状态是：硬件已就绪但贵、Linux 已支持但粗、DBMS 未改动但也能跑。对大多数团队，现在就买 CXL 服务器做生产部署为时过早；但对大内存 OLAP / HTAP 的少数团队，小规模试点（2–4 台机器）是合理的时机。

具体的”现在就该做 vs 再等 2 年”的判据：

这张表的用法是：命中左列两条及以上，值得做 pilot；命中右列两条及以上，继续观察不急于动手。

5.4 跨 AZ 和跨机柜的幻觉

有一类流行的误解：CXL 能跨机柜、跨 AZ 用。实际限制是物理层——CXL 的电气信号能走的距离和 PCIe 接近，机柜内可以走电缆（Active Electrical Cable, AEC），机柜间必须走光（CXL over Ethernet 等提案仍在草稿阶段）。即使光电转换做到位，延迟会从几百 ns 冲到几微秒，完全改变收益方程。

因此近期实际部署形态是：机柜内 CXL 2.0 / 3.0 池化，机柜间仍走 RDMA / TCP。这与 共享内存事务 里讨论的”分层协议栈”思路一致。

5.5 和其他主线的关系

• 与 共享内存事务（第 15 篇）：CXL 3.0 的硬件一致性共享，是 FaRM / Sundial 这一派协议的下一代基础设施。
• 与 近数据处理（第 17 篇）：CXL Type 2 设备可以承载 NDP 加速器，将”数据流向计算”和”计算流向数据”的边界进一步模糊。
• 与 持久内存退场之后（第 18 篇）：CXL 被视为 Optane 之后”下一代非易失内存”的主要承载路径。
• 与仓库已有文章 存储介质选型、持久内存、新硬件综述：基础硬件层的补充阅读。

六、常见坑位与踩坑清单

把上面的工程建议再压缩一下，给准备做 pilot 的团队一张”别踩坑”列表：

1. 别把 CXL 当”慢 DRAM 替换”：延迟分布不同，尾延迟放大可能把 OLTP 的 P99 打坏。pilot 前先做 3 种工作负载的对照实验（sequential scan、random point lookup、mixed OLTP）。
2. 别信厂商样机的 P50 数字：关键是 P99 / P99.9。有条件的话用 Intel MLC（Memory Latency Checker）或 AMD 的 TestMem 5 跑一遍真实延迟分布。
3. 别一次迁所有 shared_buffers：从 20% 开始，每周提 10%，看监控指标再决定。
4. 别忽视 huge page：在分层内存下 TLB miss 代价显著放大。
5. 别混用异构 CXL 设备：不同厂商的 CXL 内存卡在带宽、重试、错误处理上行为差异大。pilot 阶段同一机器上用单一型号。
6. 别忘了 ECC 和热插拔：CXL 设备的 RAS（可靠性）生态还在补，热插拔协议（CXL Hotplug）的实际支持度各家 OEM 差异巨大，生产环境慎用。
7. 别高估跨主机一致性：CXL 3.0 的 hardware coherent sharing 到 2026 年仍是早期特性，样机阶段，切勿在此之上设计商用系统。

这些是从公开技术博客、硬件厂商应用工程师、学术论文作者的访谈中反复出现的警示。“新硬件的第一个主要风险不是性能、不是价格，是未知”——这条经验在 Optane、SGX、PMEM 的历次引入中反复得到验证，CXL 没有理由例外。

七、几个值得长期盯的开放问题

写完本文最想留下的不是结论，而是三个”还没人给出答案”的问题。这些问题在未来 2–4 年会决定 CXL 能不能真正改变数据库：

1. 分层 buffer pool 的替换算法：LRU / clock 的”单层假设”被打破后，最优算法是什么？2Q、ARC、CAR 的”两级”思想能不能映射到”本地 / 远端”？还是需要完全新的 machine-learning-guided 策略？一个关联问题是”在线训练的代价”：如果策略本身需要跑模型，模型运行的 CPU 开销是否抵消了迁移带来的延迟收益？CMU 的 DB Group 在 2024 年有一篇相关预印本（待核实）给了初步答案：对访问模式相对稳定的 OLAP 负载，简单启发式已经接近最优；对访问模式剧烈变化的负载，学习型策略才值得付出开销。
2. 跨主机一致性的数据库协议：CXL 3.0 提供硬件一致性后，MVCC / 2PL / OCC 中哪些步骤可以被硬件替代？写集合检测（Write-Set Validation）完全在硬件里做是否现实？FaRMv2 的工作给了方向，但 CXL 上的版本还没出现。一个细节是崩溃恢复：硬件一致性不等于持久性，节点 crash 后 CXL 区域里的脏状态如何恢复、副本如何追齐，本质上和 RDMA-based distributed transaction 是同类问题。
3. 经济性的拐点：CXL 内存的每 GB 价格目前比本地 DDR5 贵 30%–60%（2025 年估计），只有当这个溢价降到 10% 以内，池化才会成为默认部署。这个拐点在什么时候出现，取决于内存控制器的成本而不是数据库。影响因素包括：CXL 控制器芯片的量产规模、DDR5 / DDR6 的代际迭代、以及云厂商自研 CXL 方案的比例。

这三个问题没有答案。本系列会在 2026 年 Q4 的版本里根据新论文更新本节。

参考文献

1. Compute Express Link Consortium. CXL 3.0 Specification. 2022. https://www.computeexpresslink.org/
2. H. Li et al. Pond: CXL-Based Memory Pooling Systems for Cloud Platforms. ASPLOS 2023. https://dl.acm.org/doi/10.1145/3575693.3578835
3. H. A. Maruf et al. TPP: Transparent Page Placement for CPU-Less NUMA Memory. ASPLOS 2023. https://dl.acm.org/doi/10.1145/3582016.3582063
4. D. Gouk et al. Direct Access, High-Performance Memory Disaggregation with DirectCXL. USENIX ATC 2022. https://www.usenix.org/conference/atc22/presentation/gouk
5. S. Kannan et al. Hierarchical Memory Management for Heterogeneous Large-Memory Systems. OSDI 2023.（待核实具体卷期）
6. Linux Kernel Documentation. Memory Tiering. https://docs.kernel.org/admin-guide/mm/numa_memory_policy.html
7. A. Dragojević et al. FaRM: Fast Remote Memory. NSDI 2014.
8. J. Yang et al. An Empirical Guide to the Behavior and Use of Scalable Persistent Memory. FAST 2020. https://www.usenix.org/conference/fast20/presentation/yang

上一篇：【数据库研究前沿】共享内存事务：FaRM、Sundial 与 RDMA / CXL 下的新协议

下一篇：【数据库研究前沿】近数据处理与计算下推：Smart SSD 到 DPU Offload