SQL Server-一時テーブルと物理テーブル

私の職場では、＃tempテーブルの使用をやめて、代わりにSPIDを含む永続的な物理テーブルを使用する動きが進行中です。以前に#tempテーブルにINSERTしたことがある場合は常に、たとえばストアドプロシージャの先頭にある一連INSERT INTO dbo.MyPermanentTable (SPID, ...) VALUES (@@SPID, ...)のDELETE FROM dbo.MyPermanentTable WHERE SPID = @@SPIDステートメントと共に、が必要になります。さらに、言うまでもなく、これらの「一時データを保存するための永続テーブル」が使用される場所では、を含めるように注意する必要がありますWHERE SPID = @@SPID。

このプラクティスへの移行の背後にあるロジックは、クエリが実行されているサーバーの全体的なパフォーマンスを向上させることです（tempdbのI / Oと競合を減らすことにより）。私はいくつかの理由でこのアプローチに熱心ではありません-く、潜在的に危険であり、新しいスキームを使用するクエリのパフォーマンスを損なう可能性があるようです。

#tempテーブルを削除するためのこれまたは類似のアプローチの経験はありますか？

IOや競合を減らすのではなく、両方を増やすことが非常に簡単に実証できます。

• IO：#tempテーブルから挿入、読み取り、または削除されたすべての行は、@@ SPIDテーブルから挿入、読み取り、または削除されます。しかし、すべての行は@@ SPID列が追加されて広くなるため、必要なページ数はわずかに増加し、IOはこれまでになく大きくなります。しかし、もっと重要なのは、＃tempテーブルのドロップとセッションによる新しいセッションの#tempテーブルの初期化をでシミュレートする必要があるDELETE FROM @@spidTable WHERE spid = @@SPIDため、切り捨て/作成操作（ページ範囲管理操作など）が変換されることです。行操作では、比類のないほど遅くなります。
• 競合：#tempテーブルでページロックを使用していたすべてのスキャンで、関連のないspid行でページがロックされる可能性があり、以前は存在しなかった競合が発生します。ロックエスカレーションのしきい値に達するより多くの更新を行うたびに、ロックをテーブルロックにエスカレートする機会があり、他のすべてのspid をブロックします。

したがって、tempdbで神話上のIAM / SGAM / GAMの競合に遭遇しないのは事実ですが、これが起こる唯一の理由は、通常の追加のIOおよび追加の競合のために操作がはるかに遅くなるためです。

これは抜本的な解決策のようです。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

等

tempDB内のパフォーマンスの問題をトラブルシューティングする必要があるように思えますが、ここにいくつかの提案があります