1. 课程导入与性能调优工程全景
在开始任何一次数据库服务器调优之前，先要回答一个容易被跳过的问题：我们到底在调什么，调到什么程度算完成？很多团队把调优等同于“改几个内核参数”或“加内存、换 SSD”，结果往往是某一层指标好看了，业务响应时间却没有改善，甚至因为局部优化破坏了整体平衡。本课程面向 Intel Xeon 平台上的数据库服务器，把性能调优当作一项工程来做：有目标、有边界、有输入输出、有交付物、有验收标准。
调优的目标：从业务指标倒推到资源指标
性能调优的最终目标不是把 CPU 利用率压到某个数字，而是让业务负载在可接受的资源成本下稳定满足服务水平目标（SLO）。因此目标必须分层表述：业务层关注每秒事务数（TPS）、查询平均/尾延迟（P95、P99）、并发用户数；数据库层关注 QPS、缓冲池命中率、锁等待、日志写入速率；系统层关注 CPU 利用率与频率、内存带宽、磁盘 IOPS 与延迟、网络吞吐与重传。只有把业务目标翻译成资源目标，调优才有方向。
举例说明这种翻译关系。假设某订单库要求“峰值 3000 TPS，P99 延迟不超过 20 ms”。若单条事务平均消耗 0.8 ms CPU 时间，则 3000 TPS 需要约 2.4 个物理核心持续满载，考虑峰值波动与后台任务，至少预留 4～6 个物理核心；若缓冲池命中率从 99% 降到 95%，多出的 5% 逻辑读会转为物理读，按每次物理读 0.1 ms 估算，单事务可能增加 0.2～0.5 ms，P99 就会被推高。这些数字是教学示例，用于说明“业务指标 → 资源指标”的换算思路，实际值必须通过压测获得。
调优的边界：哪些能改，哪些不能改
工程化的前提是明确边界。可调范围通常包括：BIOS 中的电源策略、超线程、NUMA、C-State/P-State；操作系统内核参数（调度、内存回收、透明大页、文件系统挂载选项）；数据库参数（缓冲池、连接数、并行度、日志刷盘策略）；存储布局（RAID 级别、条带大小、日志与数据分离）；网络（中断亲和、RSS/RPS、MTU）。不可随意改动的边界包括：业务 SQL 语义与事务一致性要求、硬件物理规格、合规与安全策略、变更窗口。把边界写清楚，才能避免“为了跑分牺牲正确性”的伪优化。
全栈性能视图：六层协同关系
数据库服务器的性能是 CPU、内存、存储、网络、数据库内核、操作系统六层协同的结果。任何一层的瓶颈都会向上传导，表现为业务延迟。下图给出本节的全栈性能视图，重点表达各层之间的依赖方向与典型观测点，而不是罗列参数。
这张图的关键在于“传导”与“反馈”两个方向：业务请求自上而下消耗资源，而资源瓶颈自下而上表现为延迟。调优时如果只盯着某一层，很容易误判。例如 CPU 利用率不高但 P99 延迟很高，瓶颈可能在存储 IO 等待或锁竞争；内存带宽饱和时，增加 CPU 核心数反而可能因 NUMA 远端访问而变慢。
交付物：调优工程的可验收产出
工程化调优必须留下可复现、可验收的交付物，而不是口头结论。建议至少包含以下五类：
- 基线报告：调优前的业务指标与各层资源指标，明确测试负载模型（并发数、数据量、读写比）。
- 瓶颈定位记录：按“现象—证据—推断—验证”记录，例如“P99 升高 → iostat 显示 await 18 ms → 推断日志盘写放大 → 调整 RAID 条带后复测”。
- 变更清单：每项改动的对象、原值、新值、依据、回滚方式。
- 复测对比：同一负载模型下调优前后的 TPS、P95/P99、资源利用率对比表。
- 结论与遗留风险：达成哪些目标、未达成项及原因、后续观察项。