内存带宽要看3个指标；容量大不等于快

内存带宽要看3个指标；容量大不等于快，这句话在采购单上体现得最直白。同样写着 16G 内存，一台是单条插在一个槽里，另一台是 8G×2 插满两个通道，页面上的数字一模一样，跑起来却是两种脾气。云主机列表页只肯给你「几核几G」，真正的差别全埋在脚注或者根本没写，等你把数据库搬上去开始卡了，才发现自己买的是那台单条。

内存带宽要看3个指标，容量大不等于快，这话怎么落到选机器上

我一般就盯三项：等效频率和代数、通道数、还有延迟——顺手再加个「每核能分到多少」。这三样基本决定了数据搬得快不快。容量是另一码事，它管的是「装不装得下」。一堆人把这两件事混成一个「越大越好」的印象，结果容量翻倍了，速度原地踏步，钱倒是花了。

频率那栏的数字，得先问是几代

DDR4-3200 和 DDR5-4800，那个 3200、4800 指的是每秒多少百万次传输（MT/s），不是 MHz，也别当成实际吞吐。理论峰值的算法很朴素：MT/s × 8 字节 × 通道数。单通道 DDR4-3200 算下来 25.6 GB/s 左右，单通道 DDR5-4800 差不多 38.4 GB/s。这是笔算出来的上限，不是厂商给你保证的到手速度。

还有个坑：条子买得再猛，CPU 内存控制器不认也白搭。标 4800 的条插在只支持到 2933 的平台上，它就老老实实按 2933 跑。另外每个通道插两条（也就是 2DPC）在不少平台上会掉一档频率，插得越满、频率越保守，这事得翻主板和 CPU 的官方规格、QVL 列表，别听装机小哥一句「都能插」。

通道数才是那道分水岭

单通道和双通道，价格差不了多少，带宽直接翻倍。服务器平台更夸张，一颗 CPU 通常挂着 6 个或 8 个内存通道（具体看平台，至强、霄龙各代不一样，以官方 datasheet 为准），你把通道插满，比把单条容量堆到天花板有用得多。

我吃过一次亏：一个图片处理的小站，进程一多就慢得离谱，第一反应是加内存，从 16G 加到 32G，问题一点没解决。后来才发现原来是单条 16G 单通道在跑，换成 8G×2 双通道，同样的核数，处理队列明显顺了。容量没变多，反而少了，速度上来了。这事儿之后我看机器第一眼先看槽位，第二眼才看容量。

延迟和每核带宽，容易被跳过

带宽是总水管粗细，延迟是水龙头到杯子的那段距离。时序里 CL、tRC 这些参数，数值越小越跟手；DDR5 的 CL 数字看着比 DDR4 大，别被吓到，那是对应更高频率的周期数，绝对延迟并没有变得多夸张，但也没白送。

更值得算的是每核带宽。32 核配双通道，把总带宽一分，每个核能拿到的就很薄了。压缩、加解密、数据库聚合、内存缓存这类活儿，全卡在这堵墙上。双路机器还得留神 NUMA：跨节点访问内存，延迟比本地节点高一截，用 numactl –hardware 看一眼节点分布，别让进程跑到对面节点上去取数据。

容量管装得下，带宽管搬得快

容量大的好处很实在：缓冲池、页缓存装得下热数据，不用天天往磁盘上换，少碰 swap。但它掩盖不了带宽不够的问题，反过来还可能惹麻烦——缓冲池开太大、page cache 吃满，OOM killer 半夜上门，这种事故我见得不算少。

也别迷信「容量大就能扛并发」。像 Redis 单实例那种单线程跑的，吞吐更看频率和延迟，内存够用就行，堆一屋子容量意义有限。反过来，跑大容量数据库的机器，容量和带宽两头都不能短，缓冲池一大，内存访问的随机性上来，带宽不够就直接体现在查询延迟上。

落到云主机上，怎么自查

能上机器的，几条命令先跑一遍：dmidecode -t memory 看每条内存的频率、槽位、rank；lshw -short -C memory 快速扫一遍；free -h 看实际可用；numactl –hardware 看 NUMA 节点。想量真实带宽就跑 STREAM，数组规模记得开得比 LLC 大，不然测的是缓存不是内存。

云主机和容器里，dmidecode 经常看不到物理条，只能看到虚拟化之后的信息，那就别猜了，直接问服务商要规格或者开工单，以他们官方页面和回复为准。至于虚拟主机，连这些都看不到，只能在业务低峰和高峰各压一遍，看延迟曲线怎么走。还有个容易忘的点：内存被超分、被邻居抢带宽，你在自己机器里怎么调都调不出来。

下次看配置单，顺序换一下：先问是几代、MT/s 多少、单条还是双条、通道插满没有，再问核数和容量。容量决定你能不能把数据放进去，带宽决定你放进去之后取出来快不快。预算实在紧，先保通道，再保频率，容量最后补——这个顺序，多数 Web 和数据库场景都不会吃亏。