数据库 CPU 100% 的真相：内存延迟
It's the Memory Latency, Stupid
当你看到数据库 CPU 使用率达到 100% 时，它真的在全力运转吗？其实，CPU 往往因为等待缓慢的内存访问而处于空转状态。现代 CPU 处理指令的速度比访问 DRAM 快数百倍，导致大量计算资源被浪费在等待数据上。文章通过对比朴素的 GROUP BY 实现与基于 radix partitioning 的优化方案，展示了如何通过将数据拆分为更小的分区来充分利用 CPU 缓存。优化后，虽然执行的指令数增加了，但 DRAM 访问量大幅减少，CPU 等待时间显著降低，最终性能得到提升。这揭示了一个核心真理：在高性能计算中，减少内存延迟往往比单纯增加计算量更有效。
如果我们将冷 DRAM 访问转化为 CPU 指令，这几乎总是一笔划算的交易。
HN 评论区
42- boricj
我在公司里和另一个团队协作，他们大量使用消息传递、在深层嵌套类层次结构中调用 C++ 虚方法、处理巨大的 DOM，以及使用现成的 C++ STL 容器……运行在 STM32MP1 上，这颗芯片用的是顺序执行的 Cortex-A7 核心，缓存小得可怜。
反观我所在的团队，我在 STM32H5 上（内存不到 1MB）写出了自定义的 C++ STL 容器，采用内联分配策略；实现了 SAX 风格的处理库；还构建了一个对象池，其链接方式使用了类似 2000 年代视频游戏中的“索引+代际”机制。
“机械共情”（Mechanical Sympathy）在我向他人演示时，感觉像是一门失传的艺术……我还不得不向第一个团队展示基准测试数据，证明我在性能上不会成为我们之间数量级级别的瓶颈。
- brcmthrowaway
https://people.freebsd.org/~lstewart/articles/cpumemory.pdf
有人为 2026 年重写这篇吗？
- drivebyhooting
我觉得文中提出的方案本质上就是一个分簇哈希表，或者按你的说法是“局部敏感”的。
但这仍然算不上数量级上的提升。
- quotemstr
呃，这难道不就是基数分区聚合（radix-partitioned aggregation）吗？分层（固定两层）聚合可是老生常谈了。这里的新意在哪里？
大概是 Pivot 项目的缩影吧。我只是不明白，既然已经有 DuckDB 和 Clickhouse 了，这个项目存在的意义是什么。
- happyPersonR
向作者致敬，方案看起来逻辑自洽。
我喜欢火焰图（flamegraphs）。
我知道大家会用 perf 来生成它们。
但未来既然有了大语言模型（LLM），不如让智能体去检查汇编代码、PMU（性能监控单元）数据，并帮你分析汇编层面到底在做什么。
以上纯属个人拙见，祝大家编码愉快 :)