1. AMD EPYC数据库服务器性能优化导论
数据库服务器的性能优化，从来不是“把某个参数调大”这么简单。它更像是在一条由硬件、操作系统、数据库引擎和业务负载共同构成的链路上，寻找真正的瓶颈并加以消除。AMD EPYC 处理器进入这一领域后，改变了传统数据库服务器的核心资源格局：单路即可提供高核心数、大容量内存通道和充足 PCIe 通道，使得“计算密度、内存带宽、I/O 吞吐”三者的平衡点发生了明显位移。本章的目标，是建立一套可复用的优化认知框架，让后续每一章的调优动作都能落到具体维度上，而不是凭经验盲目试错。
课程目标：从“会调参”到“会定位”
本课程面向已经具备一定 Linux 与数据库运维基础、希望系统掌握 EPYC 平台数据库性能优化方法的工程师。完成学习后，应能达成三个层次的目标：
- 看得懂：理解 EPYC 的 CCD、CCX、NUMA、内存通道、Infinity Fabric 等结构，以及它们如何影响数据库的延迟与吞吐。
- 找得到：面对“数据库变慢”的现象，能够用系统化方法把问题定位到 CPU、内存、存储、网络或数据库内部的具体环节。
- 调得动：针对定位结果，给出可执行的 BIOS、内核、数据库参数与 SQL 层优化方案，并用指标验证效果。
需要强调的是，优化不是追求单项指标最大化。数据库场景中，吞吐量与尾延迟往往互相牵制，CPU 利用率高并不等于性能好。真正的目标是：在给定业务 SLA 下，让资源投入与响应能力达到合理平衡。
EPYC 在数据库场景中的定位
数据库负载大致可分为两类：一类是 OLTP，特点是高并发、短事务、随机小 I/O、对延迟极其敏感；另一类是 OLAP/HTAP，特点是复杂查询、大范围扫描、并行度高、对内存带宽和计算吞吐要求高。EPYC 的架构特性恰好同时覆盖这两类需求。
以典型的第三代及以后 EPYC 为例，其核心由多个 CCD 组成，每个 CCD 内含若干核心并共享 L3 缓存；多个 CCD 通过 Infinity Fabric 与 I/O Die 相连，内存控制器和 PCIe 控制器集中在 I/O Die 中。这意味着：跨 CCD 访问会带来额外延迟，而同一 CCD 内的核心通信更快。对数据库而言，这直接决定了线程绑定、NUMA 亲和性和缓存命中率的优化空间。
同时，EPYC 单路可提供 8 通道甚至 12 通道 DDR5 内存，内存带宽远高于传统双路平台。对于以缓冲池命中为主的 OLTP，这意味着更大的有效工作集；对于 OLAP，则意味着并行扫描时不会轻易被内存带宽卡住。因此，EPYC 在数据库场景中的定位可以概括为：用单路高密度计算替代传统双路，用大内存带宽支撑大缓冲池与并行分析，用丰富 PCIe 通道支撑高速 NVMe 存储与网络。
性能优化核心维度
上图给出了四个相互作用的维度，它们共同决定数据库的最终表现。理解它们之间的耦合关系，是避免“按下葫芦浮起瓢”的关键。
CPU 与调度维度关注的是：数据库进程能否稳定运行在合适的核心上，避免跨 CCD 频繁迁移；并行查询的工作线程数是否与可用核心匹配；CPU 频率策略是否在延迟敏感场景下保持高频。实践中常见的问题是，操作系统调度器把同一事务的多个线程分散到不同 CCD，导致 L3 缓存反复失效，表现为 CPU 利用率不高但延迟偏高。
内存与 NUMA 维度关注的是：内存是否按通道均匀插满以获取完整带宽；数据库缓冲池是否绑定在本地 NUMA 节点；大页是否启用以减少 TLB 缺失。对于 EPYC 单路多 CCD 结构，NUMA 节点通常与 CCD 分组对应，若数据库进程跨节点访问远端内存，延迟可能上升数十个百分点。
存储与 I/O 维度关注的是：NVMe 设备的队列深度与中断分布是否合理；redo/事务日志与数据文件是否放在不同设备上；文件系统与块设备参数是否匹配数据库的 I/O 模式。EPYC 提供的 PCIe 通道足以直连多块 NVMe，但若中断都落在同一核心，反而会形成新的瓶颈。
数据库内核维度关注的是：连接数是否超过合理范围导致上下文切换激增；慢 SQL 是否因执行计划退化而放大资源消耗；锁等待与刷盘策略是否与硬件能力匹配。硬件再强，也抵不过一条全表扫描拖垮缓冲池。
整体方法论：先观测，再动手
性能优化最容易犯的错误，是“先改参数再看效果”。正确的方法论应当遵循一条闭环：建立基线 → 观测指标 → 定位瓶颈 → 单变量调整 → 验证效果 → 固化配置。
建立基线意味着在业务低峰或标准负载下，记录 CPU 使用率、内存带宽、I/O 延迟、数据库 QPS/TPS 与 P99 延迟等关键指标。没有基线，任何“变快了”的判断都缺乏依据。观测阶段应同时使用系统层工具与数据库层视图，例如用 perf、numastat、iostat 观察硬件行为，用数据库自身的等待事件视图观察内部争用。
定位瓶颈时，建议遵循“从外到内、从粗到细”的顺序：先确认是 CPU 饱和、内存带宽受限、I/O 排队还是数据库内部锁等待，再深入具体对象。调整阶段必须坚持单变量原则——一次只改一个参数或一个配置，否则无法判断哪个改动真正起了作用。验证阶段要回到同一负载、同一指标口径下对比，并关注尾延迟而非仅看平均值。最后，把验证有效的配置固化为基线，形成可复用的知识沉淀。
一个贯穿课程的示例场景
为便于后续章节展开，这里设定一个贯穿课程的参考场景：一台单路 AMD EPYC 服务器，运行 MySQL 8.0，承载混合负载——白天以 OLTP 订单交易为主，夜间执行报表聚合查询。初始现象是：白天高峰期 P99 延迟从 20ms 升至 120ms，CPU 利用率约 65%，iostat 显示 NVMe 利用率接近 90%，numastat 显示大量远端内存访问。
按照本章方法论，初步判断瓶颈可能同时涉及 I/O 排队与 NUMA 远端访问，而 CPU 尚未饱和说明问题不在计算能力本身。后续章节将分别从 CPU 调度、NUMA 绑定、NVMe 队列、数据库参数等角度，逐步验证并解决这一场景中的具体问题。这个场景中的数值均为教学示例，用于说明分析思路，不代表任何真实系统的实测结果。
掌握本章的维度划分与方法论闭环，后续每一章都将围绕其中一个维度深入展开，最终形成一套可落地的 EPYC 数据库性能优化能力。