8.3 调优方法论与自动化运维：把救火变成制度
8.3 调优方法论与自动化运维：把救火变成制度
本节摘要：零散的排错技巧救不了长期性能——需要的是方法论（标准调优三步加前后对比闭环）加制度（自动化巡检、配置基线、容量画像）。本节把前两节的工具与诊断学收束成日常纪律，并入自动化管理与配置管理的落地清单，最后给出性能可伸缩性设计的四条前置原则。读完你能把"个人手艺"变成"团队制度"。
调优是流程，不是灵感
标准调优三步，顺序固定。第一步定位：等待统计分诊（8.1 的账本加 8.2 的指纹卡），锁定支线与嫌疑时段，差分采样把范围缩到具体语句——这一步的产出是一句话："某语句在某时段因某类等待消耗了多少资源。"第二步取证：实际执行计划对账（估计与实际的偏离）、统计信息查验、索引使用统计复核——产出是根因假设与干预候选清单。第三步收敛：干预按成本升序试探——先统计信息（零风险）、再索引（要算写放大）、再写法（要回归测试）、最后参数与提示（要留档），每一步动完测同一把尺子。尺子必须前置定义：慢化前后的耗时、逻辑读、等待分布三件套，没有尺子的调优是玄学，有尺子的调优才是工程。
一个可复制的闭环模板。工单：报表查询午高峰超时。定位：分诊锁定 PAGEIOLATCH 居首，差分采样锚定该语句。取证：计划显示全表扫描八十万行、统计上周更新、无覆盖索引。收敛：更新统计（未改善）→ 建覆盖索引（逻辑读从八十万降到四千，耗时从九秒到零点五秒）→ 前后指标归档。结案要写三行：根因一句话、动作一句话、效果一句话——写不出来就是还没结案。归档价值在复用：同形态的案子第二次出现时，直接按卷宗走，五分钟结案。
-- 结案尺子：干预前后的同一把尺 SET STATISTICS IO ON; -- 干预前：表 '订单明细'。逻辑读 803412 次。 -- 建覆盖索引后：表 '订单明细'。逻辑读 4120 次。 SET STATISTICS IO OFF; -- 归档字段：根因 / 动作 / 逻辑读前后 / 耗时前后 / 决策人与日期
自动化巡检：让机器替你盯
人工巡检的宿命是"忙起来就忘"，答案是把它变成代理作业。一套最小巡检体系的五个作业：备份完成校验（每天查 msdb 备份历史，缺备份即告警——第 6 章策略的机器执行者）；完整性检查（每周 DBCC CHECKDB，页损坏在崩溃前暴露）；统计与索引维护（过期的统计主动更新，碎片按阈值处理，宁窄勿宽）；容量与增长（数据库与日志文件的增长率周报，tempdb 使用率阈值告警）；健康快照（每天采集等待统计、副本同步状态、作业失败次数入库，供趋势查询）。作业失败本身要有人管——"巡检作业失败三个月没人发现"是真实事故里出现过的黑色幽默，所以作业失败通知要走到人。
-- 巡检作业核心之一：备份完成校验（示例骨架） SELECT d.name AS 数据库, MAX(b.backup_finish_date) AS 最近备份 FROM sys.databases d LEFT JOIN msdb.dbo.backupset b ON b.database_name = d.name AND b.type = 'D' -- D 完整备份 WHERE d.name NOT IN (N'tempdb') GROUP BY d.name HAVING MAX(b.backup_finish_date) IS NULL OR MAX(b.backup_finish_date) < DATEADD(DAY, -2, SYSDATETIME()); -- 结果非空 = 有库超过两天没有完整备份，作业直接发通知。
配置基线与漂移：制度防的都是慢性病
配置管理的精髓是基线加漂移检测。给每个实例建档：版本与补丁级别、MAXDOP 与最大服务器内存、成本阈值、恢复模式、审计配置、代理作业清单——这份基线入版本库管理。漂移检测定期把现值与基线比对，差异进变更评审。它防的都是慢性病：某次救火临时改了 MAXDOP 没回收、新实例上线忘了对齐内存配置、有人手痒关了查询存储——单看每件都是小事，累积起来就是"同一套系统在不同实例上表现不一致"的玄学。sp_configure 的修改纪律一条就够：改动必须带工单号与理由，回滚步骤先写后改。
-- 配置快照：巡检作业每月比对一次 SELECT name, value_in_use AS 当前值 FROM sys.configurations WHERE name IN (N'max degree of parallelism', N'max server memory (MB)', N'cost threshold for parallelism', N'optimize for ad hoc workloads'); -- 与基线表 JOIN 比对，差异行进报告。快照脚本与基线同入库版本管理。
性能的可伸缩性设计还有四条前置原则，放在制度清单末尾正好：资源画像先行（没有 8.1 的基线数据，一切"优化"无法证明有效）；读写分离在架构层解决（副本与缓存分担读负载，比索引层面硬扛便宜得多）；扩展有次序（先垂直再水平——升级硬件比重写分布式架构便宜两个量级，别被"分库分表"的最佳实践绑架）；容量有预警（按增长率设水位线，容量问题要变成可预测事件而不是事故）。
巡检体系的三条落地纪律
巡检作业建成只是起点，让它长期活着靠三条纪律。失败必须可感知：每个作业配置失败通知（操作员邮件或接入告警网关），并加一条"哨兵作业"专门检查其他作业的最近结果——巡检自身失明是最危险的状态。产出必须可追溯：巡检结果写进结果表而不是只发邮件，容量曲线、备份耗时、碎片分布的历史数据，是容量规划与"以前不是这样"式争论的最终裁判。变更必须走基线：作业的调度与内容纳入版本管理，救火时的临时改动也要当天回写——巡检体系与配置基线（本节前文）共用同一套变更纪律，两套标准等于没有标准。这三条同样适用于高可用演练（第 6 章）与审计年检（第 7 章）：制度的可靠性来自"制度本身被制度管着"。
本节要点回顾
- 调优三步顺序固定：定位（等待分诊）、取证（计划与统计）、收敛（按成本升序试探），每步有产出物；
- 尺子前置：耗时、逻辑读、等待分布三件套先测后改，没有尺子的调优是玄学；
- 结案三行：根因、动作、效果写不出一句话就是没结案，卷宗的价值在第二次复用；
- 巡检五个作业：备份校验、完整性、统计索引、容量、健康快照，失败通知必须走到人；
- 基线加漂移检测：配置差异进变更评审，防的是救火遗留与新实例配置走样的慢性病；
- 伸缩四原则：画像先行、读写分离前置、先垂直后水平、容量预警化。
单机的一切到此收束。最后一章把视野推开：当数据体量与形态超出单库，SQL Server 如何作为数据平台的枢纽接入分析、机器学习与大数据生态。