（首先是一些上下文，因为虽然我希望问题足够笼统，但我们总是被告知解决方案取决于上下文。在这种情况下没有 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；我的问题是我不知道会发生什么。
鉴于我有大量空闲时间可以使用，只是进行重组有缺点吗？从描述来看，这听起来像是一个不那么侵入性的操作，只是不那么推荐，因为它是一个较旧、较慢的过程，在此过程中数据库的响应速度较慢。
我可以将重组与更新统计信息结合起来，还是这个问题表明我真的不知道索引是如何工作的？
鉴于数据库的使用模式，没有备份日志等是否有风险？
