アップロックロックヒントを使用することの副作用？
SQL-Server 2008でUPDLOCKヒントを調査していたところ、特定のデッドロックシナリオを回避するのに非常に役立つことがわかりました。これらのタイプのロックヒントを使用すると、常にいくつかの副作用がありますが、このヒントは見つかりませんでした。
それで、すべてのupdateクエリで使用するとどうなりますか？私はselectについて話しているのではなく、updateについて話しているだけです。それは私にどのような悪影響を及ぼしますか？
すべての更新クエリで使用するとどうなりますか？
すべてのヒントと同様に、UPDLOCKは明確な利点がある場合にのみ使用してください。
それは私にどのような悪影響を及ぼしますか？
クエリと実行プランによって異なります。ターゲットテーブルにUPDLOCKを追加することのみを提案していると仮定すると、非常に単純なケースではまったく悪影響がありません。
「非常に単純なケース」は、どの行が条件を満たすかについてall決定が単一のプラン演算子で行われる場合です。この状況では、更新ロックは確実に適格となる行でのみ行われるため、害はありません。
SQL Serverは、Uヒントがなくても対象となる行を検索するときにUPDLOCKロックを自動的に取得しますが、主なアクセス方法（たとえば、インデックスシークおよび関連するRIDまたはキールックアップ）に対してのみです。これらの自動Uロックは特別です。計画の後半のオペレーターが結局行が適格でないと判断した場合でも、SQL Serverはそれらを早期に解放できます。
UPDLOCKが指定されている場合、計画の他の演算子が行が実際に更新に適格でないと判断した場合でも、トランザクションが終了する前に、取得された更新ロックを解放できません。これらの追加のUロックは同時実行性を低下させ、テーブル排他ロックへのロックエスカレーションを引き起こす可能性があります。
これらの理由により、UPLOCKクエリでUPDATEを定期的に指定することは、一般的にはお勧めできません。