2. 需求调研与容量规划

容量规划不是“拍脑袋买服务器”，而是把业务语言翻译成可验证的资源数字。SQL Server 数据平台的容量规划要回答四个问题：业务要跑什么、数据会涨到多大、同时有多少人在用、需要什么样的硬件基线。这四个问题环环相扣，任何一环缺失都会导致后期要么资源不足、要么过度采购。

一、业务需求收集：从业务语言到技术指标

需求收集的核心是把“系统要快”“不能丢数据”这类模糊表述，转化为可度量的技术指标。建议按业务系统、功能模块、使用角色三个维度建立需求清单，每个条目至少记录：业务功能描述、数据来源与写入频率、查询类型（点查/范围查/聚合报表）、响应时间期望、可用性要求、数据保留周期。

例如某订单系统，业务方说“订单查询要快”。经过追问可以细化为：客服按订单号点查，期望 1 秒内返回，日均约 2 万次；运营按日期范围加状态筛选，期望 5 秒内返回，日均约 300 次；财务月度对账报表，允许 5 分钟，每月 1 次。这三类负载对索引、内存和 CPU 的要求完全不同，必须分开记录，否则后续估算会失真。

二、数据量估算：从行宽到存储

数据量估算的基本方法是：单行字节数 × 行数 × 增长系数，再叠加索引、日志和临时空间。单行字节数可按列类型累加，例如 int 4 字节、bigint 8 字节、datetime2 8 字节、decimal(18,2) 9 字节、nvarchar(50) 最多 100 字节。实际存储还要考虑行头、NULL 位图和页填充因子。

以一个订单明细表为例，假设单行约 220 字节，日均新增 50 万行，保留 3 年：

行数 = 500,000 × 365 × 3 ≈ 5.48 亿行
数据页 = 5.48亿 × 220B / 8060B ≈ 1,496 万页
数据大小 ≈ 1,496万 × 8KB ≈ 114 GB
聚集索引 + 2 个非聚集索引 ≈ 114 × 2.2 ≈ 251 GB
加上日志、tempdb、备份，规划 500 GB 较为稳妥

这里的关键是索引膨胀系数。经验上，聚集索引与非聚集索引总量常为数据本身的 1.5～3 倍，写入密集表取高值。日志空间按最大事务量和日志备份频率估算，若每 15 分钟备份一次日志，峰值事务日志可按 15 分钟写入量的 2～3 倍预留。

三、并发与增长预测

并发不能只看“在线用户数”，要看“同时活跃请求数”。常用估算方式：峰值并发 = 日均请求数 × 峰值集中系数 ÷ 86400 × 平均请求持续时间。例如日均 200 万次请求，峰值集中系数取 5，平均请求持续 0.2 秒，则峰值并发约为 23。这个数字用于判断 CPU 核数与最大工作线程配置是否匹配。

增长预测建议按“数据增长”和“负载增长”两条线分别做。数据增长按业务增长率外推，负载增长还要叠加查询复杂度变化和报表频次提升。通常按 3 年规划，第一年预留 30% 余量，第二、三年按年增长 40%～60% 滚动评估。

四、硬件资源基线设计

硬件基线由前三步的结论共同决定，核心是 CPU、内存、存储、网络四类资源。

CPU：OLTP 系统以短事务为主，核数按峰值并发 × 每请求 CPU 时间估算。若峰值并发 23、平均每请求消耗 15 ms CPU，则每秒 CPU 需求约 0.35 核，考虑峰值波动和并行查询，8～16 核是合理起点。报表类负载会触发并行度，需要额外预留。

内存：SQL Server 最有效的性能手段是把热数据和索引缓存在 Buffer Pool。若热数据约 251 GB，建议配置 256～384 GB，并通过 max server memory 为操作系统保留 10% 左右。内存不足会直接导致物理读上升，是容量规划中最常见的瓶颈。

存储：容量按数据量估算结果预留 30% 余量；性能按 IOPS 和延迟衡量。OLTP 数据盘建议 SSD，随机读 IOPS 不低于 3000，写延迟低于 5 ms；日志盘要求顺序写，IOPS 不低于 1000，延迟低于 2 ms。数据、日志、tempdb、备份应尽量分离到不同物理卷。

网络：单机场景千兆网卡通常够用；若涉及 Always On 可用性组、日志传输或分布式查询，建议万兆网卡，并单独规划心跳与数据同步网络。

五、可直接使用的容量规划表

下表可作为需求调研阶段的记录模板，字段按实际项目增删。