直接用SQL Server Maintenance Solution现成存储过程更可靠安全，因其已处理只读库跳过、在线重建判断、STATS反馈、@TimeLimit拆分及CommandLog记录等20+真实场景细节，避免自研遗漏边界条件与版本维护负担。
直接用 SQL Server Maintenance Solution 的现成存储过程，比自己写更可靠、更安全。自己硬写 DatabaseBackup、IndexOptimize 这类逻辑，容易漏掉只读库跳过、在线重建判断、@TimeLimit 拆分、CommandLog 记录等 20+ 真实边界条件，反而埋下运维隐患。
为什么别重写 DatabaseBackup 和 IndexOptimize
它们不是简单拼 SQL——而是处理大量生产细节的成熟封装：
- 自动跳过只读、离线、数据库快照或
tempdb - 对含 LOB 列或分区表，动态判断是否支持
ONLINE重建 - 备份命令自动加
WITH (STATS = 10)，避免长时间无反馈 - 大表索引操作超时后自动中断，不阻塞业务（靠
@TimeLimit） - 所有执行记录写入
dbo.CommandLog表，不是依赖作业历史
IndexOptimize 必须调优的三个参数
默认阈值（5%/30%）在 OLTP 场景下常滞后：碎片涨得快，但重建又耗资源。关键调整点：
-
@FragmentationLevel1设为 10（非 5），避免低碎片下无效REORGANIZE -
@FragmentationLevel2设为 25（非 30），让高碎片更早触发REBUILD_ONLINE -
@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，而不是依赖作业历史或错误日志。这是最权威的执行凭证——它记录了每条命令的开始/结束时间、影响行数、错误消息、执行耗时，甚至重试次数。漏看这个表，等于没真正监控。
复杂点在于：CommandLog 是按命令粒度记的，一次 IndexOptimize 可能生成几十上百条记录；筛选时得结合 DatabaseName、CommandType 和 EndTime IS NULL 查未完成项。最容易被忽略的是：没人定期清理这张表，几个月后它本身就会成为性能瓶颈。
