在我的新组织中，我们有一个60 GB的生产数据库。我们连夜从这个数据库运行了近500份报告。我注意到，所有报告脚本都在TempDB中创建表，然后填充最终报告。TempDB大小为6 GB。没有为这些从PowerShell调用的报告脚本设置依赖项。
以这种方式广泛使用TempDB是一种好的做法吗？还是最好在生产数据库中创建所有暂存表，并在生成报告后将其删除？
谢谢，房间
临时表总是在TempDb中创建的。然而，TempDb的大小不一定只是由于临时表的原因。TempDb以各种方式使用
- 内部对象（排序和假脱机、CTE、索引重建、散列联接等）
- 用户对象（临时表、表变量）
- 版本存储（AFTER/INSTEAD OF触发器，MARS）
因此，很明显，它正在各种SQL操作中使用，因此大小也可能由于其他原因而增长。然而，在您的情况下，如果您的TempDb有足够的空间正常运行，并且您的内部进程正在使用TempDb创建临时表，并且这不是问题。您可以将TempDb视为SQL Server的马桶。
您可以通过以下查询来检查是什么导致TempDb的大小增长
SELECT
SUM (user_object_reserved_page_count)*8 as usr_obj_kb,
SUM (internal_object_reserved_page_count)*8 as internal_obj_kb,
SUM (version_store_reserved_page_count)*8 as version_store_kb,
SUM (unallocated_extent_page_count)*8 as freespace_kb,
SUM (mixed_extent_page_count)*8 as mixedextent_kb
FROM sys.dm_db_file_space_usage
如果上面的查询显示，
- 用户对象的数量越多，这意味着Temp表、游标或临时变量的使用就越多
- 内部对象的数量越大，表示Query计划使用了大量数据库。例如：排序、分组等
- 版本存储的数量越多，表示事务运行时间长或事务吞吐量高
您可以通过上面的脚本监控TempDb，并首先确定其增长的真正原因。然而，60GB是一个相当小的数据库，6GB的TempDB大小是可以接受的。
上面的部分答案是从SO的另一个答案中复制的。