SQLite 中的主键是否需要索引？

It does it for you.

除了 INTEGER PRIMARY KEY 列之外，UNIQUE 和 PRIMARY KEY 约束都是通过在数据库中创建索引来实现的（与“CREATE UNIQUE INDEX”语句的方式相同）。这种索引与数据库中的任何其他索引一样用于优化查询。因此，在已经共同受 UNIQUE 或 PRIMARY KEY 约束的一组列上创建索引通常没有优势（但开销很大）。

---

如果一列被标记为 INTEGER PRIMARY KEY，它实际上是通过指定任何其他 PRIMARY KEY 或索引值进行的类似搜索的两倍左右。这是因为：

... SQLite 表中的所有行都有一个 64 位有符号整数键，用于唯一标识其表中的行 ...搜索具有特定 rowid 的记录，或搜索具有指定范围内的 rowid 的所有记录大约是两倍与通过指定任何其他 PRIMARY KEY 或索引值进行的类似搜索一样快。除了下面提到的一个例外，如果 rowid 表的主键由单个列组成，并且该列的声明类型为“INTEGER”（大小写任意混合），则该列将成为 rowid 的别名。这样的列通常称为“整数主键”。如果声明的类型名称恰好是“INTEGER”，则 PRIMARY KEY 列仅成为整数主键。其他整数类型名称，如“INT”或“BIGINT”或“SHORT INTEGER”或“UNSIGNED INTEGER”会导致主键列表现为具有整数亲和性和唯一索引的普通表列，而不是 rowid 的别名。

请参阅：http://www.sqlite.org/lang_createtable.html#rowid

---

数据库将始终默默地为唯一主键创建索引，因此它可以在内部有效地检查它的唯一性。

创建它后，它将在必要时使用它。

当然，它不会总是被集群化，如果你想要的话，你通常会在模式中指定它。

---

使用时

CREATE TABLE data(a INTEGER PRIMARY KEY, b, ...)

传统的附加（隐藏）列 rowid 将不存在：列 a 本身将是行 ID。

实际上，doc 指出：

在 SQLite 中，类型为 INTEGER PRIMARY KEY 的列是 ROWID 的别名（除了 WITHOUT ROWID 表），它始终是 64 位有符号整数。

和also

如果 [...] 表的主键由单个列组成，并且该列的声明类型是“INTEGER”[...]，则该列将成为 rowid 的别名。

由于 a 是行 ID，因此不需要索引，由于 B 树结构，对列 a 的查询将很快：

数据 [...] 存储为 B-Tree 结构，其中每个表行包含一个条目，使用 rowid 值作为键。

注意：我没有引用的 [...] 部分与普通表和带有 WITHOUT ROWID 子句的表之间的差异的精度有关，但这完全超出了这里的主题。

---