テーブルごとに nolock を指定できることに注意してください。
私は通常、複雑な SELECT クエリで nolock を使用しましたが、ほとんど変更されない小さなルックアップ テーブルと、表示のみのデータに対してのみ使用しました。現在の半年間の価格をリストした表、または ID から文字列への検索などを知っています。主要な更新でのみ変更されるものであり、その後、サーバーは通常定期的に再起動されます。
これにより、パフォーマンスが大幅に向上し、最も忙しい時間にデッドロックが発生する可能性が減少しました。さらに重要なことに、多くのテーブルにアクセスするクエリの最悪のケースの瞬間に、それが本当に顕著になりました (これは論理的であり、ロックを取得する必要がなく、それらのサイドテーブル多くの場合、ロックが必要なテーブルは 7 ～ 8 個から 4 個に減少します)
ただし、追加するときは十分に注意してください。急いだり、日常的に行ったりしないでください。適切に使用すれば害はありませんが、不適切に使用するとひどく傷つきます.
非常に重要なもの、計算するものなどには使用しないでください。一貫性がなくなり、遅かれ早かれ書き込みにつながるものは何でも.
このような別の最適化は、行レベルでのみロックする ROWLOCK です。これは主に、ログ レコードを挿入するだけのテーブルのように、行が互いに関連していないテーブルを更新 (または削除) する場合に役立ちます (そして、それらが挿入される順序は重要ではありません)。トランザクションの最後のどこかでログ レコードが何らかのテーブルに書き込まれるスキームがある場合、これもかなり高速化できます。
データベースの書き込みパーセンテージが比較的低い場合は、価値がない可能性があります。読み取り:書き込み比率は 2:1 未満でした。
この作業中に保存したいくつかの URL:
http://www.developerfusion.com/article/1688/ sql-server-locks/4/