（首先介绍一些背景信息，因为尽管我希望这些问题足够普遍，但我们总是被告知解决方案取决于背景信息。在这种情况下没有 DBA。）
这是一个[非常小的办公室]数据库，由少数客户每周使用 5 天，每天使用 8 小时，运行一个程序，该程序主要进行列表和每次少量的插入/更新。
该数据库是一个单一文件，有大约 25 个表，目前运行到 20 GB，其中 19 个由同一张表使用，该表带有 blob（image）列。
数据文件每天都会备份，但在它存在的 10 多年里从未进行过任何维护，除了将其从一台服务器移动到另一台服务器——它从 SQL Server 2005 / Windows SBS 2003 或其他东西开始，已经更改了 3 次，现在在 SQL Server 2019 / Windows 2019 上。
我认为 20 GB 太多了（对于备份来说这不是问题，系统速度足够快），但当我看到包含 blob 的表中的记录数时，我得出结论，每个 blob 大约有 300 KB，这似乎很合理。对于压缩或数据库外存储来说，这将是一个不错的选择，但我无法控制使用数据库的程序。
该表的索引碎片率为 96%。标准建议是重建并更新统计信息，但我有几个问题，最后，我希望对大家有所帮助：
重建索引是否会有导致数据库文件大小大幅膨胀的风险？（尽管它从未缩小过，并且当前大小似乎充满了有效数据而不是空的）我并不热衷于将数据库增加到 25 GB，尤其是考虑到数据很少从这个数据库中删除，只会添加。我可以容忍 1 或 2 GB 的增长；我的问题是我不知道会发生什么。
鉴于我有大量空闲时间可用，仅仅进行重组有什么坏处吗？从描述来看，这听起来像是一个干扰较小的操作，而且不太推荐，因为它是一个较旧、较慢的过程，在此期间数据库的响应速度较慢。
我可以将重组与更新统计数据结合起来吗？或者这个问题是否表明我真的不知道索引是如何工作的？
考虑到数据库的使用模式，没有日志等的备份是否存在风险？
答案1
重建索引是否会有导致数据库文件大小大幅膨胀的风险？（尽管它从未缩小过，并且当前大小似乎充满了有效数据而不是空的）我并不热衷于将数据库增加到 25 GB，尤其是考虑到数据很少从这个数据库中删除，只会添加。我可以容忍 1 或 2 GB 的增长；我的问题是我不知道会发生什么。
- 一般规则是，您需要 100% 的索引大小（与当前大小相同）以及额外的 20% 的开销。另外请记住，重建会完全记录，因此您的事务日志也会膨胀很多。最佳实践是让数据和日志文件根据需要扩展，确保驱动器上有足够的空间。
鉴于我有大量空闲时间可以利用，进行重组有什么坏处吗？
- 我至少会进行一次重组，这可以随时完成。至少这会缓解您看到的一些碎片，直到您可以安排时间进行重建。
我可以将重组与更新统计数据结合起来吗？或者这个问题是否表明我真的不知道索引是如何工作的？是的 -
- 重建会自动对您的索引运行统计。
- 重组需要手动运行统计信息（exec sp_updatestats）
从描述来看，这听起来像是一个侵入性较小的操作，而且不太推荐，因为它是一个较旧、较慢的过程，在此期间数据库的响应速度会较慢。
通过物理方式重新排序叶级页面以匹配逻辑顺序，对聚集索引和非聚集索引的叶级进行碎片整理（侵入性较低且在线完成）
重建删除并重建索引（可能会发生大多数侵入性和阻塞，并且可以离线或在线完成，具体取决于您的版本）
两者都可以消除碎片，但重建效率最高
考虑到数据库的使用模式，没有日志等的备份是否存在风险？
- 如果数据库的恢复模式为完整，则应进行事务日志备份。我假设恢复模式为简单，在这种情况下无法进行事务日志备份。此外，如果没有事务日志备份，则无法执行时间点恢复（如果需要）。这一切都由业务规定的 RTO/RPO 决定。