SQL Server-临时表与物理表

14

在我的工作场所中，正在逐渐摆脱使用#temp表，而是使用具有SPID的永久物理表的趋势。只要以前将INSERTINSERT插入#temp表中，现在INSERT INTO dbo.MyPermanentTable (SPID, ...) VALUES (@@SPID, ...)都需要一个- DELETE FROM dbo.MyPermanentTable WHERE SPID = @@SPID在存储过程开始时加上一堆语句。此外，不用说，在使用这些“用于存储临时数据的永久性表”的地方，都必须小心包含一个WHERE SPID = @@SPID。

采取这种做法的逻辑是，它将提高运行查询的服务器的整体性能（通过减少tempdb中的I / O和争用）。由于多种原因，我并不热衷于这种方法-这种方法很丑陋，潜在危险，而且似乎很可能损害那些使用新方案的查询的性能。

有没有人有这种消除#temp表的方法或类似方法的经验？

sql-server performance

— 将A
source

18

可以很容易地证明，它不会减少IO或竞争，而会同时增加两者。

IO：现在，将从#temp表中插入，读取或删除的每一行都从@@ SPID表中插入，读取或删除。但是每行都会加一个@@ SPID列，因此会更宽，因此所需的页面数将略有增加，并且IO会变得如此稍大。但更重要的是，现在必须使用来模拟#temp表的删除和会话对新会话的#temp表的初始化DELETE FROM @@spidTable WHERE spid = @@SPID，因此截断/创建操作（即页面范围管理操作）将被转换在行操作中，无与伦比的慢。
争夺：现在，每次在#temp表上使用页面锁定的扫描都可以锁定具有不相关spid行的页面，从而创建以前不存在的竞争。功能更多的每次更新命中锁升级门槛有机会升级锁表锁，从而阻止每一个其他SPID。

因此，虽然您不会碰到tempdb中的神话般的IAM / SGAM / GAM争用是正确的，但发生这种情况的唯一原因是由于普通的额外IO和争用，您的操作将变得缓慢得多。

— 雷木斯·鲁萨努（Remus Rusanu）
source

我完全同意上述Remus-感谢您的出色回应。问题是，我们在第三方应用程序上造成了预期的性能下降（服务器上有多个数据库，而我们在数据库上拥有自己的数据库-我们需要执行查询及其数据）。我仍然认为您是对的，介意-在I / O方面，我希望新方法的性能比以前差很多-从tempdbs角度来看，在竞争方面，情况会更好-从我们的角度来看，情况会更糟。

— 将在

您有几个tempdb文件？标准设置实际上根本无法扩展-您应该有多个tempdb dile和日志文件，每个可见处理器内核一个（如果是hyper-v，则每个2个）。

— TomTom

1

您必须阅读这两篇文章：sqlskills.com/BLOGS/PAUL/post/…和sqlskills.com/BLOGS/PAUL/post/…，因为它们解决了最常见的tempdb可伸缩性问题。

— 雷木斯·鲁萨努

@TomTom哇，哇。多个日志文件？真？

— 亚伦·伯特兰

5

这似乎是一个激烈的解决方案。网上有很多关于减少tempdb争用（并优化其用法）的文章-您的组织是否已彻底检查了该途径？

http://www.sql-server-performance.com/tips/tempdb_p1.aspx

http://www.sqlservercentral.com/blogs/robert_davis/archive/2010/03/05/Breaking-Down-TempDB-Contention.aspx

http://searchsqlserver.techtarget.com/tip/Optimize-tempdb-in-SQL-Server-by-striping-and-splitting-to-multiple-files

等等

+1完全同意-优化tempdb，不要重新发明轮子，因为您的实现会更糟。:)

如果没有合理的理由，我将全力以赴-感谢Ben提供的信息-我将进行调查并酌情向我们的DBA提供建议。

— 将在

2

听起来好像你应该疑难解答内tempdb中的性能问题，还有在一些建议在这里

— SPE109
source

看起来很有用-感谢SPE109，我将对此进行检查并酌情向我们的DBA提供建议。

— 将在