、多くの場合、2つのエッジの剣です。あまりにも多くは良くないし、少なすぎるとどちらもうまくいかない。
ただし、クエリに最も貢献するものを追加することで開始できます。
実行し、このスクリプト
SELECT
migs.avg_total_user_cost * (migs.avg_user_impact/100.0) * (migs.user_seeks + migs.user_scans) AS improvement_measure,
'CREATE INDEX [missing_index_' + CONVERT (varchar, mig.index_group_handle) + '_' + CONVERT (varchar, mid.index_handle)
+ '_' + LEFT (PARSENAME(mid.statement, 1), 32) + ']'
+ ' ON ' + mid.statement
+ ' (' + ISNULL (mid.equality_columns,'')
+ CASE WHEN mid.equality_columns IS NOT NULL AND mid.inequality_columns IS NOT NULL THEN ',' ELSE '' END
+ ISNULL (mid.inequality_columns, '')
+ ')'
+ ISNULL (' INCLUDE (' + mid.included_columns + ')', '') AS create_index_statement,
migs.*, mid.database_id, mid.[object_id]
FROM sys.dm_db_missing_index_groups mig
INNER JOIN sys.dm_db_missing_index_group_stats migs ON migs.group_handle = mig.index_group_handle
INNER JOIN sys.dm_db_missing_index_details mid ON mig.index_handle = mid.index_handle
WHERE migs.avg_total_user_cost * (migs.avg_user_impact/100.0) * (migs.user_seeks + migs.user_scans) > 10
ORDER BY migs.avg_total_user_cost * migs.avg_user_impact * (migs.user_seeks + migs.user_scans) DESC
（スクリプトはバートダンカンからである）
とは クエリが返すuser_scans、user_seeks、avg_user_impact、last_user_seek、last_user_scan等のような列を解析します索引作成ステートメント。よりユーザーフレンドリーになるようにインデックス名を変更することができます。 すべてのインデックスを実行するのではなく、1つずつ慎重に使用することをお勧めします。
索引付けの基本的なルール：決定コンテキスト（ 'where'、' join'、 'order by'など）で使用されるフィールドは、索引を持つ必要があります。つまり、索引が増えるとオーバーヘッドも増え、ある時点では、余分な索引をすべて保持するだけで十分なオーバーヘッドが浪費され、問合せの効率性が失われる可能性があります。 –
はい - インデックスはしばしば役に立ちます - *** IF ***どのクエリがパフォーマンス上の問題を引き起こしているかを知っていて、どのインデックスが役に立ちますか。だから、**正しい**インデックスを追加できれば、より良いパフォーマンスを得るチャンスは非常に良いですが、*見つけて**正しい**インデックスを決定することは少し難しいかもしれません... –
[SQL Serverインデックス設計ガイド]（https://technet.microsoft.com/en-us/library/jj835095(v= sql.110）.aspx） –