4.1 CPU
CPU是计算机的大脑。本节主要介绍CPU以及相关的硬件知识。
关系型数据库严重依赖其底层的硬件资源。如果对服务器硬件没有充分的了解，要想
让数据库顺畅运行，可能会遇到不可预估的挑战。对于SQL Server来说，需要关注的主要 包括以下几点：
□时钟周期速率
□核心和线程数量
□ Cache大小和类型
□指令集
4.1.1 SQL Server工作负载类型
在讨论SQL Server的性能问题时，首先要区分工作负载类型，每种类型都有不同的
侧重点及关注点，不能也不应该以偏概全。对于SQLServei■甚至其他的RDBMS,没有直 接的配置列表可以满足所有的需求，所以要根据现实的需要来进行合理地配置。在SQL
Server中，工作负载类型对硬件的选型有着极其重要的影响。不同的T 作负载，需要不同 的处理器、内存及I/O子系统。这些硬件资源又往往影响着数据库设计、索引选择，甚至
维护策略。
现代系统主要的负载类型为联机事务处理（OLTP)和决策支持系统/数据仓库
(DSS/DW ),也可以归于联机分析处理（OLAP) e 。联机事务处理和联机分析处理的特点 分别如下。
□ OLTP特点：有大量、短持续时间的事务/查询，相对高频率的写操作，CPU需要有
较高的时钟速率来支持大量的OLTP查询，并且数据的稳定性较低、易变。这类系
统会产生更高的 1OPS (input/output operations per second)操作。
□ OLAP特点：事务/查询相对少量，但持续时间很长。读操作远高于写操作，处理器
的物理核心数较多，内存控制也要求更严密，数据修改操作的运行时间相对集中（一
般在夜间)，对 I/O吞吐量要求更高。数据相对静态。
4.1.2 CPU 评估
这一节首先介绍一下在不同负载类型中的CPU相关知识，由于不同负载类型的操作行
为不同，所以对CPU的依赖也会不同。CPU是执行指令和临时存储少量内部数据缓存的地
方，它提供4 种基础服务：提取、解码、执行和存储。
在评估CPU时，除了关注CPU的能力如时钟速率（GHz)和cache大小（M B)以夕卜， 还应该关注其中涉及的某些工艺，如核心数、槽数等。
1. Cache size 和 L2/L3 caches
CPU有多级缓存，第一级L1是最低延时，但是存储容量最少；二级缓存L2延时相对
高一些，但是容量也相对更高；最后一级，也就是三级缓存L 3 ,延时最高，容量也最大，
并且现代CPU的L3通常被多个核心共享。当处理器需要执行指令或者处理数据时，会按
照下面顺序查找所需的数据：
CPU寄 存 器 L1 — L2 — L3 一内存磁盘中存在的cache —实际磁盘
常规的数据查询延时情况如图4-1所示。
现在的硬件设备运行速度越来越高，以上只是参考值，但是也能表现出其差异。这
种差异决定了在部署和设计数据库时，需要尽可能地把操作放到内存中，最好是在L2/L3
cache中运行。
SQL Server及其他关系型数据库管理系统，都严重依赖于L2和 L3的cache大小，如 果条件允许，应该选择L2/L3 cache更大的CPU ; 如果预算不足，宁愿减少RAM的开销， 也尽量不要降低CPU的性能，因为性能问题经常反映在CPU中。
如果要在两个运行速度相同的处理器之间选择，缓存（cache)越大的越好。当然成本 也会相应地越髙。
2 . 吋钟速率
时钟速率是衡量一个CPU性能的重要指标之一，这个速率的衡量比较简单，速率越大
性能越好。现在主要的处理器厂商往往通过增加处理器的时钟速度来提高CPU的性能，从
而加快单线程操作的处理速度。.
3. 多核心处理器和超线程
带有超线程的多核心处理器可以把大型任务拆分成小块并行执行，然后合并结果。这
从某种程度上来说会降低资源消耗。但是正如本书很多地方所说，对于OLTP负载，并行
操作效果并不好。
在大多数情况下，多核的性能可以达到单核的1.5倍左右，是不错的选择。也正因为这
样，在考虑使用多核心CPU还是单核心CPU时，也要考虑可伸缩性，不应该购买简单的
双槽单核系统，尽可能购买双核系统。毕竟硬件不可能经常换，升级CPU的时候这个优势
就会显现出来。
4. 高 CPU消耗的操怍：数据和备份压缩
当CPU开销很高时，内存和磁盘系统会产生不必要的压力。CPU压力可以通过增加
CPU或者升级CPU来临时解决问题，但是只有定位了瓶颈，才能从根本上解决CPU性能
问题。从 SQL Server 2008开始，出现了数据压缩和备份压缩的功能，这从很大程度上提升 了 SQL Server的性能。但是从另外一方面来讲，这两种操作都是高CPU开销的操作，它们 是通过增加CPU的使用率来降低I/O子系统压力和磁盘空间压力的。
但是不能因为消耗CPU就说压缩功能不好，比如数据压缩，数据库查询性能的好坏很
大程度取决于每次需要处理数据页的数量，简单来说就及1/0的次数，经过压缩之后，一
个数据页一般能存放更多的数据，同样的目标数据，只需要更少的数据页及I/O次数就能
完成査询，所以数据压缩从理论上而言会提升查询的性能，也能降低内存压力（因为数据
页是缓存在内存中）。但是需要提醒一下，数据压缩除了消耗CPU之外，对数据插人、更
新操作也会带来一定程度的影响，这里就体现出第一章中提到的“平衡”思想，要全面
权衡。
除了上面两种操作，SQL Server 2008还出现了针对数据库镜像的日志流压缩功能，并 且这个功能是默认开启的。通过压缩日志流，可减少同步时带来的网络压力。
5 . 超线程
超线程是选择处理器时需要考虑的另外一个重点。与物理核心不同，超线程使用的是
虚拟核心，所以必须共享相同的资源。超线程技术使得每个处理器核心都可以同时运行多
个线程。这种技术降低了计算的延时，能更好地利用每个时钟周期。
超线程直接影响SQL Server性能的一个情况是使用并行计划，如果启用了超线程，当 处理器中的其他线程未完成任务时，当前没有执行的进程都将被挂起。
但是，超线程往往并不是高效的方案，其中一个原因是L3 cache在所有逻辑处理器中 共享的，当每个逻辑处理器发生频繁的上下文切换时，会引发性能问题，称为cache冲突
( cache thrashing),而这种情况在SQL Server和 Exchange中发生的概率比较大，所以通常
来说，DBA都会禁用超线程。当然，如果新一代的超线程技术有所改善，还是可以考虑使
用的。
根据国外专家的建议，对于OLTP系统，超线程功能可以开启，但是需要严密监控效
果，而对于OLAP系统，不建议启用。在真正运行之前，没有人知道超线程是有利还是有
弊，理论毕竟是理论。与不采取超线程相比，采用超线程理论上可以将性能提升30% ,但
实际上可能只有10%〜 15%。所以如果不是在非常必要的情况下，不建议启用。
通过下面的脚本来查看硬件信息，可以得知超线程和核心方面的关系。
SELECT cpu_count AS [Logical CPU Count], hyperthread_ratio AS [Hyperthread Ratio], cpu_count / hyperthread_ratio AS [Physical CPU Count],
physical_memory_in_bytes / 1048576 AS [Physical Memory (MB) ]--2012 之前字段， 2012 之后换成 physical_memory_kb FROM sys.dm_os_sys_info
其中hypterthreadjatio列会把多核心和超线程当作一回事，也就是逻辑处理器的
个数。
6. NUMA
NUMA是非一致性内存访问（non-uniform memory access),在 NUMA系统中，每 4 个
处理器分为一组，每组都有自己的“本地”内存池。这种架构的优势在于，只要访问的数
据在本地内存池中，每个处理器最多只需要经过4 个处理器的总线距离就可以访问到。但
是如果数据在另一个NUMA节点的内存池中，那么访问成本则会偏高。使用NUMA系统
的目标之一是尽可能从本地内存池获得数据，而不用访问另外一个节点。
在这种架构下，可以支持64个处理器，但是随着系统的增大，维护缓存一致性的问题
也会随之突出，这会引人更多的管理开销。而且随着节点的增大，所需数据存储在本地内
存池的概率也会降低。
这种架构其实是通过把内存和CPU绑定分组，来减少一些访问的开销。
4.1.3 CPU 配置
高性能的CPU可以减少内存和磁盘I/O的压力。在选择CPU的时候，都希望使用最好
的 CPU ,但是现实世界总是没有那么理想，绝大部分企业都不可能不控制成本，所以在选
择 CPU时不得不做出权衡。在进行选择时，不能仅把注意力放在当前负载上，还需要考虑
一些必然的操作导致CPU达到峰值，比如：
□数据库备份。
□索引重建和重组。
□并发査询，特别是全文检索。
基于前面所述，使用多核心的CPU是较理想的选择，其中一个优势是减少SQL Server
license 费用。
对于OLTP负载，大量短事务，使用并行操作往往是不必要的，这时候可以使用单线
程性能优秀的处理器。