直接使用sql server maintenance solution的现成存储过程更可靠安全，因其已处理只读数据库跳过、在线重建判断、stats反馈、时间限制拆分及commandlog记录等20+真实场景细节，避免自研遗漏边界条件与版本维护负担。
直接用 SQL Server Maintenance Solution 提供的现成存储过程，比从零手写更可靠、更安全。自己硬写备份/索引/检查逻辑，容易漏掉边界条件、并发控制或错误回滚，反而埋下运维隐患。
为什么别自己重写 DatabaseBackup 和 IndexOptimize
这些存储过程不是简单 SQL 拼接——它们处理了大量真实场景细节：
- 自动跳过只读、离线或快照数据库
- 按文件组、分区、LOB 列等粒度判断是否支持在线重建
- 动态生成带
WITH (STATS = 10)的备份命令，避免长时间无反馈 - 对大表索引重建时，自动拆分
@TimeLimit防止阻塞业务 - 所有操作都写入
CommandLog表，便于后续监控和告警
自己实现同等健壮性，至少要覆盖 20+ 个异常分支，且需长期随 SQL Server 版本升级维护。
IndexOptimize 中必须调优的三个参数
默认阈值（5%/30%）在 OLTP 系统上往往滞后。写入频繁的业务库，碎片积累快，但重建又耗资源。关键调整点：
-
@FragmentationLevel1：设为10而非5，避免低碎片下无效重组 -
@FragmentationLevel2：设为25而非30，让高碎片更早触发重建，减少查询计划退化 -
@MinNumberOfPages：设为1000（约 8MB），过滤掉小表，省去毫秒级无意义操作
示例调用：
EXEC dbo.IndexOptimize @Databases = 'USER_DATABASES', @FragmentationLow = NULL, @FragmentationMedium = 'INDEX_REORGANIZE', @FragmentationHigh = 'INDEX_REBUILD_ONLINE', @FragmentationLevel1 = 10, @FragmentationLevel2 = 25, @MinNumberOfPages = 1000, @TimeLimit = 3600;
如何让 DatabaseIntegrityCheck 不拖垮生产库
DBCC CHECKDB 默认会加 EXCLUSIVE 锁，且内存消耗不可控。线上库必须做两件事：
- 加
@PhysicalOnly = 'Y'：跳过逻辑检查，缩短 70%+ 执行时间，适合日常巡检 - 加
@ExtendedLogicalChecks = 'N'：明确关闭扩展逻辑校验（如 LOB 完整性），除非你真需要它 - 避开业务高峰：用 SQL Server Agent 设置作业，在凌晨 2–4 点执行，且启用
@TimeLimit
注意：@PhysicalOnly 不等于“不检查”，它仍能捕获页损坏、校验和失败等致命问题。
监控失败任务必须查 CommandLog 表
所有维护操作结果都落进 dbo.CommandLog，而不是依赖作业历史或错误日志。这是唯一可信源：
- 查最近失败：
SELECT * FROM dbo.CommandLog WHERE ErrorNumber IS NOT NULL ORDER BY StartTime DESC - 查某库某天耗时最长的 5 个操作：
SELECT TOP 5 CommandType, DurationSeconds, ErrorMessage FROM dbo.CommandLog WHERE DatabaseName = 'MyDB' AND CAST(StartTime AS DATE) = '2026-06-11' ORDER BY DurationSeconds DESC - 告警脚本必须基于此表，而不是监听 SQL Server Agent 失败事件——后者可能漏掉超时被杀但未报错的任务
真正容易被忽略的是：CommandLog 表本身会持续增长，必须配定期清理策略（比如保留 90 天），否则几年后它自己就成了性能瓶颈。
