主キーとして設定されたデータベースに ID 行 (int) があるとします。ID を頻繁にクエリする場合、インデックスも作成する必要がありますか? または、主キーであるということは、すでにインデックスが作成されていることを意味しますか?
私が尋ねる理由は、MS SQL Server では、この ID にインデックスを作成できるためです。これは、前述のとおり、私の主キーです。
編集: 追加の質問 - 主キーに追加のインデックスを付けると害はありますか?
主キーとして設定されたデータベースに ID 行 (int) があるとします。ID を頻繁にクエリする場合、インデックスも作成する必要がありますか? または、主キーであるということは、すでにインデックスが作成されていることを意味しますか?
私が尋ねる理由は、MS SQL Server では、この ID にインデックスを作成できるためです。これは、前述のとおり、私の主キーです。
編集: 追加の質問 - 主キーに追加のインデックスを付けると害はありますか?
他の誰もがすでに言っているように、主キーは自動的にインデックスが付けられます。
主キー列にさらにインデックスを作成することは、主キーと他の特定の列を使用するクエリを最適化する必要がある場合にのみ意味があります。主キー列に別のインデックスを作成し、それに他の列を含めることで、クエリに必要な最適化を実現できます。
たとえば、多くの列を持つテーブルがありますが、クエリを実行しているのはID、名前、およびアドレスの列のみです。IDを主キーとして、IDに基づいて構築されているが、名前とアドレスの列を含む次のインデックスを作成できます。
CREATE NONCLUSTERED INDEX MyIndex
ON MyTable(ID)
INCLUDE (Name, Address)
したがって、このクエリを使用する場合:
SELECT ID, Name, Address FROM MyTable WHERE ID > 1000
SQL Serverは、作成したインデックスのみを使用して結果を提供し、実際のテーブルからは何も読み取りません。
注: この回答は、大規模なエンタープライズ クラスの開発に対応しています。
これは SQL Server だけでなく RDBMS の問題であり、その動作は非常に興味深いものになる可能性があります。1 つには、主キーが自動的に (一意に) インデックス付けされるのが一般的ですが、絶対的なものではありません。 主キーが一意に索引付けされていないことが不可欠な場合があります。
ほとんどの RDBMS では、一意のインデックスがまだ存在しない場合、主キーに自動的に作成されます。したがって、主キー列を主キーとして宣言する前に、主キー列に独自のインデックスを作成すると、主キー宣言を適用するときにデータベース エンジンによってそのインデックスが (許容される場合) 使用されます。多くの場合、主キーを作成し、そのデフォルトの一意のインデックスを作成できるようにしてから、その列に独自の代替インデックスを作成してから、デフォルトのインデックスを削除できます。
ここで面白い部分がありますが、一意の主キー インデックスが必要ないのはどのような場合でしょうか。テーブルが十分なデータ (行) を取得してインデックスのメンテナンスにコストがかかりすぎる場合、これは望ましくなく、許容できません。これは、ハードウェア、RDBMS エンジン、テーブルとデータベースの特性、およびシステム負荷によって異なります。ただし、通常は、テーブルが数百万行に達すると明らかになり始めます。
本質的な問題は、行の挿入または主キー列の更新のたびに、一意性を確保するためにインデックス スキャンが行われることです。その一意のインデックス スキャン (または RDBMS での同等のスキャン) は、テーブルのパフォーマンスを支配するまで、テーブルが大きくなるにつれてはるかに高価になります。
私は、20 億行、8 TB のストレージ、および 1 日あたり 4,000 万行の挿入という大きなテーブルで、この問題に何度も対処してきました。私は関連するシステムを再設計する任務を負いました。これには、ステップ 1 として実質的に一意の主キー インデックスを削除することが含まれていました。実際、再設計に近づく前に、停止から回復するためだけに、本番環境でそのインデックスを削除する必要がありました。この再設計には、主キーの一意性を保証し、データへの迅速なアクセスを提供する他の方法を見つけることが含まれていました。
デフォルトでは、主キーは常に索引付けされます。
SQL Server 2012 で主キーを定義するには、SQL Server Management Studio または Transact-SQL を使用します。主キーを作成すると、対応する一意のクラスター化インデックスまたは非クラスター化インデックスが自動的に作成されます。
非クラスター化を指定しない限り、PK はクラスター化インデックスになります。
それを主キーにすると、そのインデックスも自動的に作成されます。
SQL Server では、通常、主キーは自動的にインデックス化されます。これは事実ですが、より高速なクエリが保証されるわけではありません。主キーとしてフィールドが 1 つしかない場合、主キーは優れたパフォーマンスを発揮します。ただし、主キーとして複数のフィールドがある場合、インデックスはそれらのフィールドに基づいています。
例: フィールド A、B、C は主キーであるため、WHERE 句でこれら 3 つのフィールドに基づいてクエリを実行すると、パフォーマンスは良好ですが、WHERE 句で C フィールドのみを使用してクエリを実行する場合は、良いパフォーマンスが得られません。したがって、パフォーマンスを向上させるには、C フィールドを手動でインデックス化する必要があります。
ほとんどの場合、100 万件を超えるレコードに到達するまで問題は発生しません。
主キーは自動的に索引付けされます
使用状況に応じて、pk を使用して追加のインデックスを作成できます
(個別の) インデックスのない巨大なデータベースがあります。
主キーでクエリを実行すると、すべての集中的な目的で結果が即座に得られます。