2. AMD EPYC架构与数据库负载匹配

数据库服务器对CPU的要求与通用计算有明显差异：它更在意“可预测的延迟”和“稳定的并发吞吐”，而不是单线程峰值跑分。AMD EPYC之所以能在数据库场景中快速崛起，核心原因不只是核心数多，而是其Zen架构演进、Chiplet（小芯片）组织方式、NUMA拓扑、内存通道与PCIe通道布局，恰好能通过合理配置与数据库负载形成匹配。理解这些结构，是后续做NUMA绑定、内存通道均衡、I/O路径优化的前提。

Zen架构演进：从“追平”到“为吞吐服务”

Zen 1（2017）首次让EPYC进入主流服务器市场，采用14nm、每CCX 4核共享8MB L3，单Die最多8核，通过Infinity Fabric把多个Die连成MCM封装。它的意义在于把“每美元核心数”拉高，但跨Die访问延迟较高，数据库若不做NUMA绑定，容易出现远端内存访问拖慢事务。

Zen 2（2019，Rome）是数据库场景的关键转折：7nm计算Die（CCD）+ 12nm IO Die分离，每个CCD含2个CCX、每CCX 4核共享16MB L3，单路最高64核。IO Die集中了内存控制器与PCIe控制器，使内存与I/O延迟更一致。Zen 3（2021，Milan）把CCX扩大到8核共享32MB L3，同一CCX内核心可直接访问全部L3，显著降低数据库多线程共享热数据的延迟。Zen 4（2022，Genoa）支持DDR5与PCIe 5.0，单路最高96核，每CCX仍为8核但L3提升到32MB，并加入AVX-512，对分析型查询的向量化扫描更友好。Zen 5（2024，Turin）进一步提升IPC与内存带宽，并区分标准版与高密度版，数据库选型时需按“每核内存带宽”和“每核L3”权衡。

CCX/CCD/IO Die：数据库延迟的物理来源

EPYC的层级是：Core → CCX（核心复合体，共享L3）→ CCD（核心复合体Die，含1~2个CCX）→ Socket（多CCD + IO Die）。数据库最关心的是“共享L3的边界在哪里”。同一CCX内的线程访问共享缓存和锁结构延迟最低；跨CCX要经过Infinity Fabric；跨CCD、跨Socket则延迟逐级上升。

因此，对OLTP类负载，应尽量把同一数据库实例的工作线程、后台写线程、日志线程约束在同一CCX或同一CCD内，减少跨CCX缓存同步。对OLAP类负载，线程间共享少、扫描量大，可以更充分地铺开到全部CCD以换取并行度。IO Die则决定了内存与PCIe的“公平性”：所有CCD通过Infinity Fabric访问IO Die上的内存控制器和PCIe Root Complex，若某CCD距离目标内存通道较远，延迟会略高，这就是NUMA拓扑在EPYC上格外重要的原因。

NUMA拓扑：数据库必须“看见”的边界

在EPYC上，NUMA节点通常按CCD或CCX划分，每个节点拥有本地内存通道。数据库进程若把线程和内存分散到多个节点，跨节点访问会带来额外延迟。以MySQL为例，可通过numactl --hardware查看节点分布，再用numactl --cpunodebind=0 --membind=0把实例绑定到单个节点。对于单实例高并发OLTP，建议“一个实例一个NUMA节点”，避免跨节点锁竞争；对于需要大内存缓冲池的实例，可开启innodb_numa_interleave让内存在节点间交错分配，用带宽换延迟稳定性。

判断是否绑定成功，可观察numastat中numa_hit比例是否接近100%，以及numa_foreign是否接近0。若numa_miss持续偏高，说明线程在访问远端内存，应检查绑定策略或调整实例线程数。

内存通道与PCIe通道：吞吐与延迟的“水管”

EPYC Genoa提供12个DDR5通道，Turin进一步提升到12通道DDR5-6000。数据库的缓冲池命中率再高，也仍需要从内存读取页面，因此内存带宽直接决定扫描类查询和checkpoint的吞吐。配置时应把DIMM均匀插满所有通道，避免“只插一半通道”导致带宽腰斩。以12通道DDR5-4800为例，理论带宽约460GB/s；若只插6条，实际可用带宽可能降到约230GB/s，OLAP扫描时间会明显拉长。

PCIe方面，EPYC提供128条PCIe 5.0 lanes，可拆分为多组x16/x8。数据库的I/O路径包括：NVMe数据盘、日志盘、网卡。建议把日志盘与数据盘分到不同PCIe Root Complex或不同NUMA节点，避免日志写入与数据读取争抢同一上行链路。对于RDMA网络，应把网卡插在靠近数据库实例所在NUMA节点的PCIe插槽，减少跨节点DMA延迟。可用lspci -tv确认设备挂载的Root Complex，再用numactl把网卡中断绑定到同节点CPU。

匹配原则：按负载类型选择拓扑策略

OLTP高并发短事务：优先单NUMA节点绑定，减少跨CCX缓存同步；线程数不超过单节点物理核数，避免调度到远端。OLAP大扫描：可跨节点铺开线程，但需保证内存交错分配，并让NVMe盘分散到多个PCIe Root Complex。混合负载：用cgroup或数据库资源组把OLTP与OLAP实例隔离到不同CCD，减少L3争抢。

实际选型时，可用以下示例参数做快速估算：若单节点8核、L3 32MB，OLTP实例建议并发线程≤8，缓冲池≤节点本地内存的70%；若整机96核、12通道DDR5，OLAP实例可开到64~80线程，但需确认numastat的numa_hit≥95%。这些数值属于示例参考，实际应以压测结果为准。

归根结底，EPYC的Chiplet设计把“核心数”和“内存/IO”解耦，给了数据库更多可调空间，但也要求DBA理解CCX、CCD、IO Die与NUMA的对应关系。只有让数据库负载的线程、内存、I/O路径与物理拓扑对齐，才能把EPYC的吞吐优势转化为稳定的低延迟。