テーブルのインデックスが未使用であると判断する

無関係なインデックスを見つけるためにこのスクリプトを実行しています

select o.name as TableName, i.name as IndexName, p.reserved_page_count * 8.0 / 1024 as     SpaceInMB, s.*
from     sys.dm_db_index_usage_stats s
inner join sys.objects o on s.object_id = o.object_id
inner join sys.indexes i on i.index_id = s.index_id and i.object_id = o.object_id
inner join sys.dm_db_partition_stats p on i.index_id = p.index_id and o.object_id =      p.object_id
where o.name = ‘TableName’

last_user_seek / scan / lookupがすべてnullの場合、最後の再起動以降にインデックスを使用したユーザーはいないことを知っています。しかし、私はsystem_scans / lookups / seeksが何なのか疑問に思っています。特定のテーブルで、ユーザーアクティビティのない5個を見つけましたが、10日前にシステムアクティビティを1個見つけました。システムスキャン/シーク/ルックアップがどのようなものであるかについての洞察はありますか？これらのテーブルは本当に過剰にインデックス付けされているようで、脂肪を減らしたいと思います。

インデックスのメンテナンス（再構築/再編成）およびDBCC CHECKDBアクティビティの可能性が高く、おそらく統計の更新。定期メンテナンスは構成されていますか？

ユーザーアクセスがない場合は、ビンに入れます。使用されなくなったと判断する時間枠に注意してください。たとえば、毎週または毎月のレポートタスクはありますか？

探している間に、重複したインデックスも調べてください。

編集：SSCリンクについて

スレッド全体のクイックスキャンから、SSCの人々は同様の考えを持っていたように見えます。しかし、彼らはこれらのインデックスの「時折の」使用の可能性に対してより慎重な姿勢を取っています。反論は、それは正反対であり、誰かがそれを行うのは正しいことだと思ったが、理解の欠如またはテストの欠如を通じてそうではなかったからだと言っているということです。

未使用の重複するインデックスを削除する以外に何もせずに、2つのシステムを危機から回復させました。過剰なインデックス作成は混乱を引き起こす可能性があります。

それはあなたのシステムです。これらのインデックスを残したり、削除したりするリスクを理解し、比較検討する必要があります。ドロップを続行することにした場合は、何をするのか、なぜそれを行うのかを文書化し、インデックスのスクリプトを作成し、すべての関係者に公開します。

グレンベリーは、不足しているインデックスを見つけるのに役立つ素晴らしいスクリプトをいくつか作成しました。タスクの推測作業の一部を使用する彼のスクリプトを使用することをお勧めします。これらのスクリプトは、nullまたは0のユーザールックアップ/スキャン/シークを探しているだけでなく、読み取りアクティビティと書き込みアクティビティの間に大きなスキューがあるインデックスを探しています。彼のスクリプトをチェックアウトします- 彼のこの投稿から始めることができます。

システムアクティビティについて心配する必要はありません。これは、インデックスを削除しても悪化することはありません。実際、そのインデックスが存在するため、そのインデックスでのみ発生するアクティビティである可能性があります。主な関心事は、ユーザーの読み取りアクティビティとユーザーの書き込みアクティビティであり、それらのバランスを取ることです。

インデックスは、使用されていない場合でも、クエリオプティマイザーに有用な情報を提供することに注意してください。たとえば、一意性の影響についてはかなりのことをしました。シークまたはスキャンがないために一意のインデックスを削除しても、パフォーマンスに悪影響を与える可能性があります。

他の皆が述べたことに加えて、参照されたFK列に対するインデックスはシークやスキャンを決して表示しないかもしれませんが、裏で使用されます。