我正在寻找一个意见，我知道这通常是不受欢迎的，所以我提前道歉。
我目前处于每个实例都是 SQL Server 企业版的环境中。维护任务由自定义计划执行。默认情况下，此计划在夜间进行离线重建。
没有夜间维护窗口，并且由于环境是多国的，维护的“夜间”部分并不总是意味着最低活动点（但在 95% 的情况下确实如此）。由于积极的索引维护，目前有很多夜间作业运行缓慢。（一个报告查询在等待一个包含客户数据的 300GB 表的索引重建时卡住了，导致我走上了这条路线）
我可以假设以下内容将产生主要的积极影响：
- 添加 10% 的最小碎片值进行重组（目前每天晚上完成，无论 %）
- 将最低重建要求更改为 30%（目前为 5%）
- 将默认行为更改为 ONLINE
- 将最小页数更改为 1000（当前为 50）
我在这里主要要问的是，我是否正确假设当前的维护计划过于激进。并且上述 4 项变化将产生净积极影响。
我最担心的是每天晚上为所有事情重新组织一切......这似乎太过分了。
我们很难知道这是否会是一个净积极因素。这些几乎是显而易见的：
不过，您仍然应该测试这些。
但是我们不知道碎片整理/重建对您的读取工作量有什么影响，以及是否推迟到某个百分比更好，您什么也得不到，甚至可能使某些读取查询变得更糟。
其他人已经完善了这种类型的维护，并将您从猜谜游戏中带走。获取Ola Hallengren 的脚本或我们的工具Fragmentation Manager。您只需更改参数值即可按照您的建议进行更改。而且不要忘记，这些人已经解决了很多你还没有遇到的错误，并且想到了你还没有想到的事情。当新版本在线提供新操作，或为不同的维护功能添加新选项时，这些工具和脚本将为您更新。你所做的被亲切地称为重新发明轮子：
由于过去的投资而拒绝转向更自动化的解决方案，这有点像因为你去年付了钱而留下了一个糟糕的管家或园丁。有时你只需要剪断电源线。
我假设数据库是高度事务性的，需要重建；并且是国际化的，随时可以访问...所以在我看来，一切都保持原样，并改为在线重建。
一切都是浪费的；但不是火车粉碎。轻松完成任务检查碎片 - 将其设置得稍微不那么激进 - 10% 碎片然后重新组织；20% 然后重建。
因此，您只引入了 2 个更改，再次评估和调整。这样，您就可以考虑可选而不是所有时间；和在线，这样您就可以让人们访问。
按照建议，检查 Ola Hallengren 的工作。编码的绝妙例子......鼓舞人心。
祝你好运！
主要区别在于：
离线索引重建比在线重建更快。
SQL Server 联机索引重建期间需要额外的磁盘空间。
通过 SQL Server 联机索引重建获得的 SQL Server 锁。
此模式修改锁会阻止所有其他对表的并发访问，但它只会在很短的时间内保持很短的时间，同时删除旧索引并更新统计信息。