複数のクライアントを持つDBキューとしてSQLServerを使用する

テーブルをキューとして使用することをお勧めします。適切に実装されたキューは、数千の同時ユーザーを処理し、1分あたり最大50万のエンキュー/デキュー操作を処理できます。 SQL Server 2005までは、ソリューションは煩雑で、SELECTを混在させる必要がありました。およびUPDATE gbnによってリンクされた記事のように、単一のトランザクションでロックヒントの適切な組み合わせを提供します。幸いなことに、出力句が登場したSQL Server 2005以降、はるかに洗練されたソリューションが利用可能になりました。現在、MSDNはOUTPUT句の使用を推奨しています。

テーブルをキューとして使用するアプリケーション、または中間結果セットを保持するアプリケーションでOUTPUTを使用できます。つまり、アプリケーションは常にテーブルに行を追加または削除しています

基本的に、これが非常に同時の方法で機能するために正しく理解する必要があるパズルの3つの部分があります：

自動的にデキューする必要があります。行を見つけて、ロックされた行をスキップし、単一のアトミック操作で「デキュー」としてマークする必要があります。ここで、OUTPUT 条項が機能します：

    with CTE as (
      SELECT TOP(1) COMMAND, PROCESSED
      FROM TABLE WITH (READPAST)
      WHERE PROCESSED = 0)
    UPDATE CTE
      SET PROCESSED = 1
      OUTPUT INSERTED.*;

あなたはしなければならない PROCESSEDの左端のクラスター化されたインデックスキーを使用してテーブルを構成します桁。 IDの場合主キーが使用された後、クラスター化されたキーの2番目の列として移動します。 IDに非クラスター化キーを保持するかどうかの議論コラムは開いていますが、しないことを強くお勧めしますキュー上にセカンダリ非クラスター化インデックスがある場合：

    CREATE CLUSTERED INDEX cdxTable on TABLE(PROCESSED, ID);

このテーブルを他の方法でクエリするのではなく、デキューする必要があります。ピーク操作を実行しようとしている、またはテーブルをキューとして使用しようとしている店舗として可能性が高い デッドロックが発生し、スループットが大幅に低下します。

アトミックデキュー、デキューする要素を検索するためのREADPASTヒント、および処理ビットに基づくクラスター化インデックスの左端のキーの組み合わせにより、同時負荷が高い場合でも非常に高いスループットが保証されます。