クエリがtempdbへの流出を引き起こすのはなぜですか？

バックグラウンド

私は、48 GB RAMを搭載したWin 2008サーバー上のMSSQL 2008（標準）から、64 GB RAMを搭載したWindows 2012上のMSSQL 2012（64ビットWebエディション）を実行する新しいサーバーに160 GBデータベースを移行しています。古いサーバーは稼働しており、負荷がかかっています。新しいサーバーは運用されていません。新しいサーバーには、8つのtempdbファイル（各4GB）があります。

問題

新しいサーバーでのテストでは、多数のクエリで「実行中にデータをスピルするためにtempdbを使用した演算子」という警告が表示されることがわかりました。いくつかのクエリを書き直すことでソートを回避できましたが、これは実際には問題に対処していません。古いサーバーで同じクエリを実行しても、流出は発生しません。MSSQLがメモリ内の操作を完了できず、tempdbにスピル/ページングする必要がある場合、スピルが発生することを読みました。流出を心配する必要がありますか？

例

データベースでsp_updatestatsを実行したため、統計は最新である必要がありますが、推定行数と実際の行数にいくつかの相違があることに注意してください。

メモリの懸念

64 GBの58のMSSQLの最大メモリ設定を設定しました。現在、MSSQLはこのメモリを約35GB消費していますが、ワーキングセットはわずか682MBです。古いサーバー（本番環境ではありますが、負荷を処理します）には、44gbのメモリがMSSQLにコミットされており、そのうち43.5gbがワーキングセットに含まれています。

こぼれがメモリ設定に関連している可能性があるかどうかはわかりません-誰にもアイデアがありますか？現在、MSSQLにはエーカーのRAMがありますが、なぜある種の並べ替えやハッシュの一致のためにtempdbにこぼれるのですか？

ここにはいくつかの異なる質問があります：

Q：以前にクエリがこぼれなかったのはなぜですか？

しかし、SQL Server Management Studioは、SQL 2012より前のリリースではこれを明確なエラーとは見なしていませんでした。パフォーマンスチューニングを行う場合、グラフィカルな実行プランよりも深くする必要があることの良い例です。

Q：クエリがディスクに流出するのはなぜですか？

SQL Serverが操作を完了するのに十分なメモリを許可しなかったためです。おそらく、実行計画が必要なメモリ量を過小評価しているか、ボックスがメモリ不足になっているか、単に大きなクエリである可能性があります。（SQL Serverは、生データページのキャッシュ、実行計画のキャッシュ、クエリ用のワークスペースの3つのことのためにメモリを使用します。ワークスペースメモリはかなり小さくなります。）

Q：流出を減らすにはどうすればよいですか？

サーガブルT-SQLステートメントを記述し、最新の統計情報を取得し、サーバーに十分なメモリを配置し、適切なインデックスを構築し、期待どおりに動作しない場合の実行計画を解釈します。チェックアウトグラントFritcheyの著書SQL Serverクエリパフォーマンスチューニングを、それらのすべての詳細な説明のために。