私たちのデータベースは多くのテーブルで構成されており、そのほとんどは整数の代理キーを主キーとして使用しています。これらの主キーの約半分はID列にあります。
データベース開発は、SQL Server 6.0の時代に始まりました。
これらのインデックス最適化のヒントにあるように、最初から続いているルールの1つは、増分キーに基づいてクラスター化インデックスを作成しないことです。
現在、SQL Server 2005とSQL Server 2008を使用して、状況が変わったという強い印象を持っています。一方、これらの主キー列は、テーブルのクラスター化インデックスの完全な最初の候補です。
回答:
神話は、行レベルのロックを追加した SQL Server 6.5以前に遡ります。そして、カレン・デラニーによってここでほのめかされました。
これは、データページ使用の「ホットスポット」と、挿入された行ではなく、2kページ全体（SQL Server 7以降は8kページを使用）がロックされたという事実に関係していました。
Kimberly L. Trippによる信頼できる記事が見つかりました
ホットスポットは、ページレベルのロックのためにSQL Server 7.0よりも前に回避しようとしたものです（これがホットスポットという用語が否定的な用語になった場所です）。実際、否定的な用語である必要はありません。ただし、ストレージエンジンは（SQL Server 7.0で）再設計/再設計され、真の行レベルロックが含まれるようになったため、（ホットスポットを避けるための）この動機はなくなりました。
編集、2013年5月
lucky7_2000の答えのリンクは、ホットスポットが存在し、問題を引き起こす可能性があると言っているようです。ただし、この記事ではTranTimeで一意でないクラスター化インデックスを使用しています。これには、uniquifierを追加する必要があります。これは、インデックスが厳密に単調に増加しない（および幅が広すぎる）ことを意味します。その回答のリンクは、この回答または私のリンクと矛盾していません
個人的なレベルでは、クラスター化されたPKとしてbigint IDENTITY列を持つテーブルに毎秒数万行を挿入したデータベースで目覚めました。
要約すると、最近のSQL Serverバージョンでは、ID列のクラスター化されたキーが最近の推奨オプションです。
Kimberly Trippには、このトピックに関する素晴らしいブログ投稿があります。私は言い換えることができますが、私を信じて、私はそれを正しません。読んでください。 http://www.sqlskills.com/BLOGS/KIMBERLY/post/Ever-increasing-clustering-key-the-Clustered-Index-Debateagain!.aspx
そこにいる間、キーのクラスタリングのトピックに関する彼女の他の投稿をチェックしてください。彼女のサイトから得られる豊富な知識があります。
この投稿を確認してください：
増分キーに基づいてクラスター化インデックスを作成すると、パフォーマンスに悪いホットスポットが作成される場合があります...