简介：数据库性能优化中，CPU与内存资源分配常被忽视却直接影响系统稳定性。SQL Server 2008 R2 的并行查询机制依赖 MAXDOP 与 cost threshold 两个核心参数，默认配置会让低开销查询过度并行，导致 CPU 冲高；而无上限的 max server memory 则可能引发操作系统内存换页。合理设定并行度、并行阈值与内存上限，能显著降低资源争用、提升吞吐和响应速度。这些调优手段广泛应用于 OLTP 生产环境与 DBA 日常运维，尤其适合硬件资源有限但业务负载较重的老旧实例。围绕 SQL Server 2008 R2 的 sp_configure 配置实践，这里给出可直接执行的优化步骤与常见问题判断方法。
1. 单独调 SQL Server 2008 R2 的 CPU 和内存分配，是因为默认配置撑不住真实业务
装完 SQL Server 2008 R2 直接上业务，是不少团队走过的弯路。默认安装的配置只保证“能跑”，不保证“跑得快”。在一台 16 核、64GB 内存的服务器上，默认的 max degree of parallelism 是 0，意味着所有查询都可以无限并行；cost threshold for parallelism 是 5，意味着开销超过 5 的查询就并行。这个组合在并发一高时，立刻把 CPU 吃满，查询互相抢资源。内存侧一样，默认的 max server memory 不设上限，SQL Server 会慢慢把系统内存占光，最后操作系统开始换页，整个实例性能断崖式下跌。这篇文章面向的是正在维护 SQL Server 2008 R2 的 DBA 和运维工程师，把 CPU 和内存的分配逻辑拆开，给出可直接执行的配置方法和踩坑清单，让这台老实例在现有硬件上把性能顶到极限。
2. CPU 侧的最大化：从 max degree of parallelism 到 affinity mask
2.1 并行度参数：为什么默认值 0 在 OLTP 上容易翻车
SQL Server 2008 R2 里控制 CPU 并行的核心参数是 max degree of parallelism（简称 MAXDOP），默认值 0 表示使用所有可用的 CPU 核心。单看字面意思，用满所有核心不是好事吗？实际不是这样。OLTP 业务的特点是大量短查询，每条查询本身的 CPU 开销很小，但当 MAXDOP 为 0 时，SQL Server 会把很多短查询也拆到多个 CPU 上并行执行。并行执行有固定开销：分发任务、收集结果、线程同步，这些开销在小查询上反而超过串行执行，查询变慢，CPU 却多了不少无谓消耗。
常见的做法是把 MAXDOP 限制在 4 或 8，具体取决于服务器核心数和业务类型。我一般会先看数据库里的查询特征：如果是报表类、分析类的长查询为主，MAXDOP 可以设高一点；如果是交易类、写入类为主，设 4 比较稳妥。设置方法用 sp_configure，脚本如下。
-- 查看当前 MAXDOP 配置 SELECT name, value, value_in_use FROM sys.configurations WHERE name = 'max degree of parallelism'; -- 开启高级配置，否则 sp_configure 改不了 MAXDOP EXEC sp_configure 'show advanced options', 1; RECONFIGURE WITH OVERRIDE; -- 把并行度限制为 4 EXEC sp_configure 'max degree of parallelism', 4; RECONFIGURE WITH OVERRIDE;这段脚本先读当前值，再开启高级选项，最后把 MAXDOP 改成 4。RECONFIGURE WITH OVERRIDE 是让配置立即生效，不需要重启服务。注意 value 列是当前会话看到的配置值，value_in_use 是实际生效的值，如果两者不一致，说明有配置在等待重启或 RECONFIGURE。
MAXDOP 到底设多少，网上有各种说法，但真正靠谱的依据是我们自己的硬件拓扑和业务特征。单实例独占物理机时，按核心数的 25% 到 50% 取整比较合理。比如说 16 核服务器，MAXDOP 设 4 或 8；如果是 8 核，设 4。如果实例同时还在跑其他应用或虚拟化，MAXDOP 要更保守一些，因为 CPU 资源不只是 SQL Server 在用。判断是否出了问题的办法很简单：改完观察一周，看 CPU 使用率和平均查询耗时，如果 CPU 降下来了、查询反而更快，说明之前的设置偏激进。
2.2 按工作负载设并行阈值：cost threshold for parallelism 的参考公式
MAXDOP 管的是“最多用几个核”，cost threshold for parallelism 管的是“开销多大才允许并行”。默认值 5，这个值低得离谱。在 SQL Server 2008 R2 的成本模型里，很多简单的索引查找、小范围扫描，成本都超过 5，结果就是一批本不该并行的查询被送进并行计划，白白消耗 CPU 资源。我经手的生产环境里，把 cost threshold 从 5 调到 30 或 50，CPU 使用率普遍能降 20% 到 30%。
常见的调整方式是先用 DMV 找出系统中实际运行的查询成本分布，再设定阈值。但很多团队的生产库不允许随便跑分析脚本，那么用参考公式也行：以 MAXDOP 为 4 的服务器为例，cost threshold 设在 25 到 50 之间，报表类业务取高值，OLTP 取低值。设置脚本和 MAXDOP 类似。
EXEC sp_configure 'show advanced options', 1; RECONFIGURE WITH OVERRIDE; -- 设置并行代价阈值为 50 EXEC sp_configure 'cost threshold for parallelism', 50; RECONFIGURE WITH OVERRIDE; -- 验证生效 SELECT name, value, value_in_use FROM sys.configurations WHERE name IN ('cost threshold for parallelism', 'max degree of parallelism');改成 50 之后，开销低于 50 的查询全部走串行计划，高于 50 的才允许并行。这样做的效果是：小查询不再被并行机制拖累，大查询依然能利用多核加速。有人担心设太高会导致大查询并行不充分，实际不用太紧张，因为 SQL Server 的成本估算本身偏保守，50 的阈值已经能过滤掉绝大多数短查询。真正的坑在于并行查询计划缓存，改完 cost threshold 后，缓存里的旧计划不会立即失效，需要观察一段时间或手动触发计划重编译。
还有一个细节容易忽略：cost threshold 是全局参数，但查询可以用 OPTION (MAXDOP n) 提示单条覆盖。对于已经确定的高并发短查询，我一般建议在应用层加上 MAXDOP 1 的查询提示，保证它在任何全局配置下都串行执行。全局参数和局部提示同时存在时，局部提示优先。这种做法在生产环境中被验证过多次，比单纯调全局参数更精细。
2.3 affinity mask 与 NUMA：什么时候真的需要绑核
affinity mask 是 SQL Server 里用来把调度器绑定到特定 CPU 核心的参数，默认值是 0，表示不绑定，所有核心都可以被 SQL Server 使用。很多 DBA 第一次见到这个参数就想去绑核，实际上在大多数场景下，绑核带来的收益很小，反而可能降低整体吞吐。真正需要绑核的场景是：服务器上同时运行着其他重量级应用，或出现了明显的 NUMA 跨节点访问延迟。
SQL Server 2008 R2 是 64 位实例为主，affinity mask 分两组：32 位用 affinity mask，64 位用 affinity64 mask。查看和设置的方法如下：
-- 查看当前 affinity 配置 SELECT name, value, value_in_use FROM sys.configurations WHERE name LIKE 'affinity%'; -- 把 0-3 号 CPU 核心绑定给 SQL Server（二进制 00001111 转十进制是 15） EXEC sp_configure 'show advanced options', 1; RECONFIGURE WITH OVERRIDE; EXEC sp_configure 'affinity mask', 15; RECONFIGURE WITH OVERRIDE;这里的 15 是位掩码。0-3 号核心对应二进制 1111，转十进制是 15。如果要绑 4-7 号核心，对应二进制 11110000 转十进制是 240。绑核之后，SQL Server 的调度器只会在绑定的核心上运行，能避免与其他进程争抢，但也意味着未绑定的核心闲置，系统总吞吐降低。所以绑核前必须确认：这台服务器是不是 SQL Server 独占？如果是独占且 NUMA 架构明显，不需要绑核，SQL Server 自己会感知 NUMA 并优化调度。如果是混合部署，绑核才有意义。
NUMA 节点方面，SQL Server 2008 R2 在安装时会自动识别 NUMA 拓扑，并且默认开启软 NUMA。我不建议在没做压力测试的情况下去手动调整 NUMA 节点分配，因为一旦配置错误，查询的跨节点内存访问会更频繁，性能反而下降。检查当前 NUMA 配置和调度器映射，可以用下面这段 DMV 查询。
-- 查看每个调度器对应的 CPU 和 NUMA 节点 SELECT scheduler_id, cpu_id, parent_node_id, current_tasks_count FROM sys.dm_os_schedulers WHERE status = 'VISIBLE ONLINE' ORDER BY scheduler_id;这段查询返回每个调度器绑定的 CPU 和 NUMA 节点编号。如果发现某个 NUMA 节点下的调度器数量明显不平衡，才考虑用 affinity mask 调整。一般来说，绑核是最后的手段，不是优化的起点。很多生产环境的 CPU 性能问题，根源是 MAXDOP 和 cost threshold 设置不合理，而不是调度器没绑好。
3. 内存侧的最大化：max server memory 与缓冲池的平衡
3.1 max server memory 应该留多少给系统：8GB 到 512GB 的参考值
SQL Server 2008 R2 的内存管理机制和后续版本差别很大，简单说就是它会根据系统可用内存动态扩张缓冲池，直到把内存吃光，触发操作系统的内存压力。默认的 max server memory 是 2147483647 MB，也就是说没有上限。这就是很多 SQL Server 服务器出现物理内存耗尽、操作系统开始用页面文件的直接原因。设置 max server memory 是刻不容缓的事。
留多少给系统，取决于服务器的物理内存总量和其他进程占用。我一般参考这个区间：服务器总内存 8GB，SQL Server 的 max server memory 设为 5GB 到 6GB；16GB 内存设 12GB 到 14GB；32GB 设 26GB 到 30GB；64GB 设 55GB 到 60GB；128GB 以上，预留 8GB 到 16GB 给操作系统和运维工具即可。这些数值已经考虑了 Windows 本身大概占 2GB 到 4GB，以及杀毒软件和监控代理的占用，具体还要看这台机器上跑什么。设置脚本如下：
-- 查看当前内存配置 SELECT name, value, value_in_use FROM sys.configurations WHERE name IN ('max server memory (MB)', 'min server memory (MB)'); -- 设置最大内存为 60GB（61440MB） EXEC sp_configure 'show advanced options', 1; RECONFIGURE WITH OVERRIDE; EXEC sp_configure 'max server memory (MB)', 61440; RECONFIGURE WITH OVERRIDE;这个脚本把 SQL Server 的内存使用上限限制在 60GB，实例会逐渐把缓冲池收缩到这个范围以内。注意 max server memory 是软上限，SQL Server 不会立即释放所有超出的内存，而是根据内部压力慢慢回收。设置后要观察几分钟，用性能监视器看 SQL Server:Memory Manager 的 Total Server Memory (KB) 是否在下降。
最大的风险是设置过小。如果 max server memory 设得太低，缓冲池装不下热数据，查询必须频繁读取磁盘，性能会暴跌。判断合适与否的指标是缓冲池命中率，这个放到后面避坑章节细说。还有一个容易被忽略的问题：SQL Server 2008 R2 的 max server memory 不限制非缓冲池内存，比如查询编译缓存、CLR、连接上下文等。所以即使设置了合理上限，也可能出现 SQL Server 进程实际内存超过限制的情况。这是老版本的设计特点，不用太吃惊，只要总量在可控范围内即可。
3.2 min server memory 的作用和误用
min server memory 的默认值是 0，表示 SQL Server 启动后不会一口气把内存吃到某个水平，而是按需分配。很多人误以为把 min server memory 设成和 max server memory 一样，可以让 SQL Server 一直保持高性能，实际上这是个误区。min server memory 只在系统内存压力较大的时候有意义：当操作系统内存不足，试图回收 SQL Server 的页面时，SQL Server 会尽量把内存维持在这个下限以上，避免缓冲池被压缩到过小。
在 SQL Server 2008 R2 里，min server memory 我一般不会设，或者只设一个很低的值，比如 1GB 或 2GB。如果设得过高，SQL Server 启动时会预分配大量内存，导致其他应用启动变慢，甚至在物理内存不足时出现交换风暴。一个更合理的做法是让 max server memory 承担主要限制职责，min server memory 保持默认。只有在同机部署了多个 SQL Server 实例时，min server memory 才用来保证每个实例至少拿到基本内存。
-- 设置最小内存为 2GB EXEC sp_configure 'show advanced options', 1; RECONFIGURE WITH OVERRIDE; EXEC sp_configure 'min server memory (MB)', 2048; RECONFIGURE WITH OVERRIDE;设置 min server memory 后，SQL Server 启动阶段就会尝试预留 2GB 内存给缓冲池，这对单实例低负载场景反而是一种浪费。而且 SQL Server 2008 R2 的内存管理是动态收缩和扩张的，min server memory 过高会干扰缓冲池的自动调优逻辑，可能导致内存明明充足却无法充分利用。我只能说，这个参数在大多数生产环境里保持默认就是最合适的，不是所有能调的参数都值得调。
3.3 lock pages in memory 与 32GB 以上实例的注意点
lock pages in memory（锁定内存页）是 Windows 上的一项权限，授予 SQL Server 服务账户后，SQL Server 的内存页不会被操作系统换出到磁盘。在 32 位系统上，这个选项曾经是启用 AWE 内存的关键；到了 64 位 SQL Server 2008 R2，它的作用变成了防止缓冲池中的内存页被页面文件回收。这个设置在内存较大的生产实例上值得做，但操作步骤比较隐蔽，很多人不知道在 SQL Server 2008 R2 里需要手动授予权限。
具体的操作不是用 SQL 语句，而是在 Windows 组策略里设置。给服务账户授予“锁定内存页”权限，然后重启 SQL Server 服务。64 位实例默认不会启用锁定内存页，需要手动设置。开启后可以用 DMV 检查 AWE 是否生效。
-- 检查是否已启用锁定内存页 SELECT sql_memory_model, sql_memory_model_desc FROM sys.dm_os_sys_info;在 SQL Server 2008 R2 中，这个查询返回的 sql_memory_model_desc 为 CONVENTIONAL 时表示未启用锁定，AWE 或 LOCKED_PAGES 表示已生效。启用后最大的好处是内存不会再被换出，查询速度稳定；代价是操作系统无法回收这部分内存来应对突发内存需求。所以我只建议在物理内存充足且 SQL Server 独占的服务器上启用。如果服务器内存吃紧，启用锁定内存页后系统反而更容易进入卡死状态。
32GB 以上的实例还要注意另一个问题：SQL Server 2008 R2 的每个用户数据库在 32 位实例上有 4GB 的上限，但 64 位没有这个限制。如果你的实例还是 32 位，内存优化的前提是先升级到 64 位，否则 max server memory 设多大都没用，缓冲池照样上不去。
4. 用 T-SQL 和 sp_configure 一次性完成 CPU 与内存分配：可直接抄的脚本
4.1 查看当前 CPU 和内存配置的查询语句
在改动之前，先把当前状态摸清楚。SQL Server 2008 R2 的配置信息集中在 sys.configurations 视图里，但很多关键参数默认不显示，需要先开启 show advanced options。下面的脚本会把和 CPU、内存相关的所有参数一次性列出来。
EXEC sp_configure 'show advanced options', 1; RECONFIGURE WITH OVERRIDE; -- 列出 CPU 和内存相关配置 SELECT name, value, value_in_use, minimum, maximum, is_dynamic FROM sys.configurations WHERE name IN ( 'max degree of parallelism', 'cost threshold for parallelism', 'max server memory (MB)', 'min server memory (MB)', 'affinity mask', 'affinity64 mask', 'awe enabled', 'lightweight pooling' ) ORDER BY name;这段查询的关键在于 value 和 value_in_use 的对照。value 是 SQL Server 当前会话读到的配置值，value_in_use 是实际运行生效的值。正常情况下两者一致；如果不一致，意味着配置改动后还没有执行 RECONFIGURE，或需要重启服务。is_dynamic 字段表示这个参数是否支持在线修改，比如 max server memory 是动态的，但 affinity mask 在 2008 R2 里修改后需要重启。
我习惯把这套查询保存成一个视图脚本，放到每台服务器的标准维护目录里。改动前跑一遍，改动后再跑一遍，对比结果就能确认参数是否生效。比起靠记忆去猜当前配置，这种方式更稳妥，也不会在给新同事交接时漏掉关键信息。
4.2 设置并行度、内存上限和 affinity 的执行脚本
如果要在新服务器上完成一轮完整的 CPU 和内存配置，可以按下面这套顺序执行。以一台 16 核、64GB 内存、64 位 SQL Server 2008 R2 实例为例，推荐的配置是：MAXDOP 4，cost threshold 50，max server memory 60GB，min server memory 保持默认 0，affinity mask 保持默认。组合脚本如下：
EXEC sp_configure 'show advanced options', 1; RECONFIGURE WITH OVERRIDE; -- CPU 并行度限制为 4 EXEC sp_configure 'max degree of parallelism', 4; RECONFIGURE WITH OVERRIDE; -- 并行代价阈值提升到 50 EXEC sp_configure 'cost threshold for parallelism', 50; RECONFIGURE WITH OVERRIDE; -- 内存上限 60GB EXEC sp_configure 'max server memory (MB)', 61440; RECONFIGURE WITH OVERRIDE; -- 检查结果 SELECT name, value, value_in_use FROM sys.configurations WHERE name IN ( 'max degree of parallelism', 'cost threshold for parallelism', 'max server memory (MB)' );执行顺序上，建议先改内存上限再改 CPU 参数。原因是内存限制恢复生效后，系统整体压力下降，再调整并行度时不容易因为内存不足导致 RECONFIGURE 缓慢。每个 RECONFIGURE WITH OVERRIDE 都会检查参数间的依赖关系，比如 max server memory 必须大于 min server memory，否则会报错。
这套脚本在 SQL Server 2008 R2 上不要求重启服务，全部是动态参数。但 affinity mask 和 awe enabled 在修改后需要重启。如果某台服务器之前被其他人改过 affinity mask，需要先确认当前值，避免在已有绑核配置基础上叠加修改，导致 CPU 资源被错误分配。
4.3 确认生效与重启要求：哪些参数需要重启
不是所有配置改动都能即时生效，SQL Server 2008 R2 的参数分三类：动态参数（即时生效）、需要 RECONFIGURE 的参数、必须重启服务的参数。CPU 和内存相关参数中，max server memory、min server memory、MAXDOP 都是动态的，改完立即生效，无需重启。但 affinity mask、affinity64 mask、awe enabled 在 2008 R2 上属于需要重启的参数，改完必须重启 SQL Server 服务才能看到效果。
判断是否要重启的通用方法：改完参数后执行 RECONFIGURE，如果提示“配置选项已更改，但某些选项只有在服务器重新启动后才会生效”，就说明需要重启。也可以直接查 sys.configurations 的 is_dynamic 字段。下面是确认是否已生效的脚本：
-- 查找所有已修改但尚未生效的配置 SELECT name, value, value_in_use FROM sys.configurations WHERE value <> value_in_use;这个查询的价值很大：它能把所有配置值和生效值的差异一次性找出来。如果修改完参数后忘了重启，value 和 value_in_use 会不一致，查询结果里就能看到哪些参数处于“改了但没用上”的状态。生产环境里，经常有 DBA 改完 affinity mask 后忘记重启，过了几天排查性能问题时才发现配置没生效，白白浪费了时间。
重启 SQL Server 服务会导致所有连接中断，必须安排在维护窗口内。如果服务器上有多个实例，重启顺序先备库后主库，避免主库重启期间业务直接停摆。另外，重启前一定把当前配置用脚本输出留存，万一重启后参数被某个启动脚本覆盖，可以快速对比找回。
5. SQL Server 2008 R2 优化 CPU 和内存的常见问题与避坑清单
5.1 现象：设置 max server memory 后系统依然卡顿
设置了 max server memory 为 60GB，服务器物理内存有 64GB，理论上 SQL Server 应该限制在 60GB，但系统还是卡。打开任务管理器发现 SQL Server 进程实际内存仍然接近 63GB 或更高。原因：max server memory 在 SQL Server 2008 R2 里只限制缓冲池的大小，不限制所有内存使用；查询计划缓存、连接上下文、CLR 等部分不计入 max server memory。还有可能是锁定内存页被启用后，SQL Server 的虚拟内存预留超过物理内存。
解决：先确认是否有其他进程在跟 SQL Server 争内存，再看 SQL Server 进程的“工作集”和“提交大小”区别。如果实际内存超标幅度不大，比如 1GB 到 2GB，可以接受；如果超标严重，需要进一步检查是否有内存泄漏的第三方组件或大量内存 Grant。也可以把 max server memory 调低一点，留出更多余量给非缓冲池内存。这个现象在 2008 R2 上很常见，不用反复去核对进程内存，关键是看有没有触发操作系统的内存压力。
5.2 现象：开启并行查询后 CPU 飙到 100%
MAXDOP 从 0 改成 4 之后，CPU 反而飙到 100%，查询也没变快。原因分析下来，问题很可能不在 MAXDOP，而是 cost threshold for parallelism 太低。默认值 5 让大量短查询进入并行，这时 MAXDOP 限制的只是并行度上限，并没有减少并行查询的数量。并行操作的调度开销、上下文切换反而让 CPU 更忙。
解决：把 cost threshold 从 5 提到 50，观察 CPU 曲线。同时检查是否有查询因为统计信息过期，导致优化器错误评估成本，把本应串行的查询送进并行。更新统计信息后再看执行计划，通常能稳定下来。另外一个坑是服务器开启了超线程，Windows 和 SQL Server 会看到逻辑处理器数量翻倍，MAXDOP 设成逻辑核心数会导致并行线程过度竞争，按物理核心数设置更稳妥。16 物理核、32 逻辑核的服务器，MAXDOP 设 8 比较合适。
5.3 现象：32 位实例内存上限永远用不满
服务器物理内存 16GB，但 SQL Server 实例怎么设置 max server memory 都只能用到 3GB 左右，buffer pool 命中率明显偏低。原因：SQL Server 2008 R2 的 32 位实例在未启用 AWE 的情况下，用户模式地址空间只有 2GB 到 4GB，max server memory 设再高也没用。64 位实例没有这个问题。
解决：升级到 64 位实例是根本办法。如果短期无法升级，可以通过启用 awe enabled 参数并授予服务账户锁定内存页权限来使用超过 4GB 的内存，但 32 位 AWE 的稳定性和性能远不如 64 位。遇到 SQL Server 2008 R2 的内存瓶颈，优先确认实例是 32 位还是 64 位，这个基础信息经常被忽略。在 SQL Server 2008 R2 中，32 位模式已经是边缘场景，大多数生产环境都是 64 位。
5.4 现象：改完配置后实例无法启动
修改了 affinity mask 或 awe enabled 参数后，重启 SQL Server 服务，实例启动失败，错误日志提示配置无效或无法分配内存。原因：affinity mask 的值超出了系统实际 CPU 核心数量，或者 awe enabled 开启后没有正确授予锁定内存页权限，导致服务无法初始化内存管理模块。
解决：用单用户模式启动 SQL Server 实例，恢复默认配置。启动命令大概是 sqlservr.exe -f -c -m，然后在单用户模式下执行 sp_configure 把问题参数改回原值。如果没有保留原值，至少要把 affinity mask 改回 0，awe enabled 改回 0。这里最重要的一条经验是：在改动需要重启的参数之前，先把现有配置值完整记录，包括 value 和 value_in_use，这样即便翻车也有后悔药可吃。
5.5 现象：内存优化后缓冲池命中率反而下降
调整 max server memory 之后，Buffer Cache Hit Ratio 从原来的 99% 掉到了 90%。看起来像内存设置变小导致缓存不够用，实际上可能是内存压力引发的连锁反应。原因：原来的实例内存无上限，缓冲池能保留大量数据页，命中率当然高；设置限制后，缓冲池收缩，部分热数据被挤出，命中率下降是正常现象。关键看查询的物理读是否增加，如果物理读没有明显上升，说明命中率下降的影响有限。
解决：用性能监视器对比调整前后的 Physical Disk Reads/sec 和 Page Life Expectancy。只要磁盘读没有增长，命中率略降可以接受。另一种情况是 min server memory 设置过高，导致缓冲池无法收缩，日志文件和其他缓存拿不到内存，命中率也受影响。把 min server memory 降到 0 或 1GB，让内存管理回到动态模式。这个问题的核心是判断命中率下降是否真的影响业务，而不是盯着数字本身。
6. 上线前的验证方法：用性能计数器确认 CPU 和内存真的“最大化”了
6.1 五分钟性能基线：Processor、内存与 SQL Server 关键计数器
配置改完，别急着宣布优化完成，先跑一轮性能基线。我在生产环境里习惯抓取以下计数器各五分钟：Processor 的 % Processor Time、Memory 的 Available MBytes、SQL Server:Buffer Manager 的 Buffer cache hit ratio 和 Page life expectancy、SQL Server:SQL Statistics 的 Batch Requests/sec、SQL Server:Memory Manager 的 Total Server Memory (KB)。采集工具可以用 Windows 性能监视器，也可以用脚本定期抓取。关键是数据要落在同一个时间轴上，方便对照分析。
6.2 找瓶颈的简单判断规则
拿到计数器数据后，套用一组简单规则判断是否还有问题。CPU 方面，% Processor Time 持续超过 80% 且 Batch Requests/sec 没有明显增长，说明 CPU 还是瓶颈，需要检查是否存在大量并行查询或者编译重编译。内存方面，Available MBytes 持续低于 500MB，说明系统内存还是紧张，需要再调小 max server memory 或者排查其他应用；Page life expectancy 低于 300 秒，说明缓冲池中的数据页周转太快，可能内存上限设得太小或者磁盘读取存在压力。
6.3 一个习惯：所有配置改动在测试环境先跑一遍
我之前吃过一次亏：生产环境的 SQL Server 2008 R2 上直接修改了 MAXDOP 和 cost threshold，改完之后一台服务器的 CPU 立刻打满，查询大面积超时，最后只能紧急改回原配置。后来养成的习惯是任何配置改动先在测试环境用同样的硬件配置跑一遍，执行压力脚本观察计数器变化，确认无异常再上生产。SQL Server 2008 R2 的配置参数之间相互影响，同一个值在不同硬件和业务负载下的表现可能完全不同，跳过验证直接上生产是在赌运气。
CPU 和内存的参数调整不是一次性任务，业务负载会变，数据量会涨，半年前调好的配置现在可能不再合适。我每隔一个季度会重新抓一次基线，和上一次对比，如果 CPU 使用率长期偏高或 Page life expectancy 持续偏低，就重新评估 MAXDOP、cost threshold 和 max server memory 的取值。这种周期性的小调整比一次大改更安全，也更容易定位是哪个参数变化导致了性能波动。希望这些方法能帮你在自己的 SQL Server 2008 R2 实例上少走弯路，把现有硬件的价值真正压榨出来。
本文还有配套的精品资源，点击获取
