我发现我们的数据库具有完整恢复模型，并且具有 3GB 事务日志。
随着日志变大，这将如何影响数据库的性能以及访问数据库的应用程序的性能？
最佳答案
推荐的最佳实践是为 SQL Server 事务日志文件分配其自己的磁盘或 LUN。
正如其他发帖者所提到的，这是为了避免磁盘上事务日志文件的碎片，并且还避免/最小化磁盘争用。
理想的情况是让您的 DBA 提前为您的数据库环境分配足够的日志空间，即一次性分配 x GB 的数据。在专用磁盘上，这将创建连续的分配，从而避免碎片。
如果您需要增加事务日志，那么您应该再次努力以相当大的 block 来执行此操作，以便努力连续分配。
您还应该注意不要收缩事务日志文件，因为重复收缩和自动增长可能会导致磁盘上的数据文件碎片。
我发现最好将自动增长数据库属性视为故障保护，即您的 DBA 应该主动监视事务日志空间(可能通过设置警报)，以便他们可以相应地增加事务日志文件大小来支持您的数据库使用要求但自动增长属性可以确保您的数据库在发生意外增长时可以继续正常运行。
较大的事务日志文件本身如果不会对性能产生不利影响，因为 SQL Server 会按顺序写入日志，因此只要您适本地管理整体日志大小和额外空间的分配，您就不必担心。
关于sql-server - 大事务日志如何影响性能？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1251570/