SQL Serverの複数のワーカーのFIFOキューテーブル
次のstackoverflowの質問に答えようとしました： 複数のサーバーアプリケーションインスタンスで個々のテーブル行を処理するには、どのSQL Server 2005/2008ロックアプローチを使用する必要がありますか？ やや素朴な答えを投稿した後、私は自分の口がどこにあるかを考え、実際に私が提案しているシナリオをテストしました。まあ、それは思ったよりもはるかに難しいことが判明しました（誰にも驚きはありません、確かです）。 ここで私が試し、考えたことがあります： まず、派生テーブル内でORDER BYを使用して、TOP 1 UPDATEを試しましたROWLOCK, READPAST。これによりデッドロックが発生し、アイテムの順序が狂って処理されました。同じ行を複数回処理しようとすることを必要とするエラーを除いて、可能な限りFIFOに近い必要があります。 私は、その後の様々な組み合わせを使用して、変数に所望の次のキューIDを選択しようとしたREADPAST、UPDLOCK、HOLDLOCK、及びROWLOCK排他的にそのセッションによって更新するための行を保存します。私が試したすべてのバリエーションは、以前と同じ問題に悩まされていましたREADPAST。 READ COMMITTEDまたはREPEATABLE READ分離レベルでのみREADPASTロックを指定できます。 READ COMMITTED であったため、これは混乱を招きました。以前にこれに遭遇したことがあり、イライラします。 この質問を書き始めてから、Remus Rusaniが質問に対する新しい回答を投稿しました。私は彼のリンクされた記事を読んで、彼が破壊的な読み取りを使用していることを確認しました。彼は答えで、「Webコールの間、ロックを保持することは現実的に不可能です」と述べた。更新または削除を行うためにロックが必要なホットスポットとページに関する彼の記事の内容を読んだ後、探していることを行うために正しいロックを実行できたとしても、それはスケーラブルではなく、大規模な並行性を処理しません。 今、どこに行けばいいのかわかりません。行の処理中にロックを維持することはできません（高tpsまたは大規模な同時実行性をサポートしていなくても）。私は何が欠けていますか？ 私より賢い人と私より経験のある人が助けてくれることを期待して、私が使用していたテストスクリプトを以下に示します。TOP 1 UPDATEメソッドに切り替えられますが、他のメソッドを残し、コメントアウトしてありますので、あなたもそれを調べたいと思います。 これらをそれぞれ別のセッションに貼り付け、セッション1を実行してから、他のすべてをすばやく実行します。約50秒でテストは終了します。各セッションからのメッセージを見て、どのような作業を行ったか（またはどのように失敗したか）を確認してください。最初のセッションでは、存在するロックと処理中のキューアイテムの詳細を2回目に撮影したスナップショットを含む行セットが表示されます。それは時々機能し、他の時間はまったく機能しません。 セッション1 /* Session 1: Setup and control - Run this session first, then immediately run all other sessions */ IF Object_ID('dbo.Queue', 'U') IS NULL CREATE …