SQLiteの主キーにインデックスは必要ですか？
整数列がSQLiteテーブルの主キーとしてマークされている場合、インデックスも明示的に作成する必要がありますか？ SQLiteは主キー列のインデックスを自動的に作成するようには見えませんが、目的を考えれば、とにかくインデックスを作成するのでしょうか？ （私は常にその列で検索します）。
文字列主キーの場合、状況は異なりますか？
INTEGER PRIMARY KEYカラムは別として、UNIQUE制約とPRIMARY KEY制約の両方は、データベースにインデックスを作成することで実装されます（ "CREATE UNIQUE INDEX"ステートメントと同じ方法で）。このようなインデックスは、クエリを最適化するためにデータベース内の他のインデックスと同様に使用されます。その結果、UNIQUEまたはPRIMARY KEY制約の対象となる列のセットにインデックスを作成しても、多くの場合利点はありません（ただし、大きなオーバーヘッド）。
列がINTEGER PRIMARY KEYとマークされている場合、実際には他のPRIMARY KEYまたはインデックス値を指定して行われる同様の検索の2倍です。それの訳は：
... SQLiteテーブル内のすべての行には、そのテーブル内の行を一意に識別する64ビット符号付き整数キーがあります...特定のROWIDを持つレコード、または指定された範囲内のROWIDを持つすべてのレコードの検索は、約2倍です他のPRIMARY KEYまたはインデックス付きの値を指定することによって行われる同様の検索として高速。
以下に示す1つの例外を除き、ROWIDテーブルにプライマリキーがあり、単一の列で構成され、その列の宣言された型が "INTEGER"大文字と小文字が混在している場合その後、列はROWIDのエイリアスになります。
このような列は、通常「整数主キー」と呼ばれます。 PRIMARY KEY列は、宣言された型名が正確に「INTEGER」である場合にのみ整数主キーになります。 「INT」、「BIGINT」、「SHORT INTEGER」、または「UNSIGNED INTEGER」などの他の整数型の名前は、主キー列が、rowidのエイリアスとしてではなく、整数アフィニティと一意のインデックスを持つ通常のテーブル列として動作するようにします。
データベースは常に一意の主キーのインデックスをサイレントに作成するため、効率的に一意であることを内部的に確認できます。
作成したら、必要なときに使用します。
もちろん、常にクラスター化されるわけではありません。必要に応じて、通常はスキーマで指定します。