メールキューのテーブルを使用します。新しいメールを送信する必要がある場合は、このテーブルに挿入されます。テーブルには、statusというインデックスが付いたフィールドがあります。即時削除によるSQL Serverのキュー最適化
スクリプトは10秒ごとに実行され、ステータス= 0の新しいメールがあるかどうかを確認し、このメールを送信してステータスを1に更新します（実際のメールコンテンツはnvarchar(max)列として保存されます）。
私の質問：電子メールが送信されたら、レコードを別の "送信済み"テーブルにコピーしてメールキューテーブルから削除するという意味で、テーブルをすぐに "クリーニング"するのに利点はありますか？現在、毎月約50万件のメールを削除して、このクリーニングプロセスを月に1回しか実行していません。
あなたがここにいくつかの操作のパフォーマンスを検討する必要があります。新しい電子メールの
すぐに削除の問題に対処する：ディスクスペースに問題がない場合は、削除する最も早い方法データは、テーブル全体を切り捨てることです。 1ヶ月に1回。
インサートのパフォーマンスは、異なるアプローチを選択することによって影響を受けるべきではありません。インサートの時間は、表のサイズ（表記のロック）と物理構造によって異なります。だから、ロックになるとすぐに行をきれいにしないほうがいいでしょう。
「送信済み」フラグの更新は、ここで最も難しい部分です。最初に新しい電子メールで行を選択し、実際に送信した行を更新する必要があるため、表のサイズは大きな役割を果たします。私はあなたがループ内で1つずつ電子メールを送信するためにカーソルを使用すると仮定するので、送信されるすべてのアイテムのIDを見つけるために必要なものは1つだけです。フラグ列にクラスター化されていない索引がある場合は、リソースを消費するべきではありません。インデックスを維持することを忘れないでください。ただし、それは営業時間外に処理することができます。いったん電子メールを送信すると、フラグを更新するためにそのIDを使用して行にアクセスすることができます。したがって、IDフィールドにクラスタード・インデックスがある場合（これが望ましい場合があります）は、高速操作です。
すべてのことで、テーブルをすぐにクリーニングすることは効果がないと言いたいのですが、そのためにロックするので、インデックスを削除したり選択したり更新したりするとそれほど利益が得られませんそのアプローチから。
あなたのスクリプトを実行するのに正当な時間があり、メールの量が多い場合、あなたのやっていることは正しいです。メールを送信することは、テーブルをクリーニングすることよりも非常に重要です。
洗浄プロセスあなたは月額このくらいのメールを送信measnあなたはmonth.Thatあたり5,00,000のレコードを言っているので、-delete
を選択し、選択-insertが必要です。 10秒あたりのメール=
選択500000/30、16666 /（24 * 60 * 60.0）* 10 = 2メールを選択します。
あなたは10秒ごとに2つのメールを送信します。
私はあなたが1つの操作ですべての操作を行うことができると思います。ステータス= 1の更新時にデータをアーカイブに移動するトリガーを作成するように。
第2スケジューラは不要です。