MS-SQL中是否可以有一个'持久'临时表？我的意思是我目前有一个后台任务，它生成一个全局临时表，由各种其他任务使用（这就是为什么我把它全局化）。不幸的是，如果表未被使用，它会被SQL自动删除 - 这是由我的系统优雅地处理，因为它只是将它排队再次重建，但理想情况下我希望它只是每天构建一次。所以，理想情况下我可以设置类似设置一些超时参数的东西，比如“如果没有触及这个1小时，那么删除”。
我真的不希望它在我现有的数据库中，因为它会导致负载更多与管理数据库相关的麻烦（碎片，日志增长等），因为它有效地汇总数据，仅在24小时内有用，并且占用超过一千兆字节的高清空间。
最糟糕的情况我的计划是在与tempdb相同的驱动器上创建另一个数据库，称之为类似PseudoTempDB，并且只是自己处理。
非常感谢任何见解！
答案 0 :(得分：6)
如果您创建一个表为tempdb.dbo.TempTable，它将不会被删除，直到：
a - 重新启动SQL Server
b - 您明确删除它
如果您希望它始终可用，您可以在模型中创建该表，以便在重新启动期间将其复制到tempdb（但它也将在您之后创建的任何新数据库上创建，因此您将必须手动删除）或使用启动存储过程来创建它。但是，无法通过重新启动来持久保存数据。
答案 1 :(得分：3)
我会选择你的计划B，“在与tempdb相同的驱动器上创建另一个数据库，称之为类似PseudoTempDB，并且只是自己处理丢弃。”
答案 2 :(得分：2)
我不得不承认对这个问题进行双重考虑：“持久性”和“临时性”通常不会在一起！一点开箱即用的想法怎么样？也许您的后台任务可以定期运行一个简单的查询，以防止SQL将表标记为未使用。这样，你就可以直接控制创造和拆除。
答案 3 :(得分：2)
如何创建永久表？说，MyTable。每24小时刷新一次数据：
这样，您每天都在重新创建表格。
如果您担心日志文件，请将表存储在其他数据库中并将其设置为Recovery Model：Simple。
答案 4 :(得分：0)
经过20年处理所有现有主要RDBMS的经验，我只能提出几点建议供您考虑：
请注意矛盾的概念：“持久”和“温度”是完全相反的。选择一个，然后选择一个。
您并不是在以手动，半永久性，用户驱动的方式将数据库写入临时数据库中。普通表空间（即用户）已经存在。临时数据库是临时性的。
如果您已经知道这样的表将被永久使用（“每日”是永久性的），则将其创建为用户数据库/架构上的普通表。
每次删除并重新创建相同的表时，都会使整个数据库碎片化。并且拥有永远不会给DB引擎优化器提供任何协助您进行任何粗略优化的机会的不正当好处。而是尝试将其截断。您的回滚段将感谢您的小小的努力，第二天再次填充时，可能仍会分配磁盘空间。您可以通过仅为该表指定单独的表空间和数据文件来强制执行所需的行为。
最后，更重要的是：停止破坏您和您的DB引擎以获取仅1 GB的数据。您要浪费CPU，I / O周期，增加延迟，碎片等等，以节省0.02美分的硬件实际状态。谈论穿着燕尾服掉落在地板上以捡起一棕分。 ?