短命の列のほとんどの適切なインデックス

Question

私の現在のプロジェクトでは、「変更された」という名前の列があります。これは、最後のチェックから現在の行が変更されたかどうかを示します。すべての挿入ステートメントと更新ステートメントにはこの列が含まれています。

1時間ごとに、変更されたすべての行を照会し、それらの行でいくつかの処理を行い、その後にnullを「変更済み」列に設定するスケジュール済タスクを実行します。

この列で書き込み操作と読み取り操作を頻繁に行う予定であるため、パフォーマンス上の問題が発生する可能性があります。インデックスは常に再構築されます。

（この種のメカニズムを使用するのではなく）このシナリオにはどのような最適なオプションがありますか？

Answer 1

テーブルが巨大な場合は、列を削除して専用テーブル（主キー情報のみ）を作成し、このテーブルにトリガを挿入します。この小さなテーブルを処理し、行を完成させるときにそれをクリアする必要があります。トラッキングする各テーブルに対してこれを行う必要があります。

テーブルが小さい場合は、悪い考えではありませんが、これらのテーブルで選択と更新が多く、スケジュール処理がループしているか遅い場合はブロック/ロックが発生することがあります。

カラムを使用する場合は、LastChgDateカラムを使用する方が良いでしょう。その後、範囲内のすべての行を処理するだけです（毎回処理する範囲を追跡する必要があります）。それが完了したことを示すためにLastChgDateを変更する必要があります。あなたの予定されたプロセスが実際の行を更新しているのに、あなたが言うことがないなら、これは疑問に思うかもしれません。

Answer 2

カラムには2つの値（変更された場合はnullと1）しかないため、インデックスはおそらく無意味です。