Question

这就是我的表格：

CREATE TABLE pics(
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  name TEXT,
  page INTEGER,
  w INTEGER,
  h INTEGER,
  FOREIGN KEY(page) REFERENCES pages(id) ON DELETE CASCADE,
  UNIQUE(name, page)
);

CREATE INDEX "myidx" ON "pics"("page");  # is this needed?

所以UNIQUE(name, page)应该创建一个索引。但是这个索引是否足以进行仅涉及page字段的快速查询？就像选择一组“照片”WHERE page = ?一样。还是JOIN pages.id ON pics.page？或者我应该为页面字段创建另一个索引（myidx）吗？

Answer 1

如上所述，您需要另一个myidx索引，因为您的UNIQUE索引首先指定name。换句话说，它可以用于查询：

name
name和page
但仅<{1}} 不。

您的另一个选择是重新排序page索引，并将UNIQUE列放在第一位。然后，它只能用于page查询，但只会与page查询不兼容。

Answer 2

将复合索引视为电话簿。电话簿按姓氏排序，然后是名字。如果您的名字是 Bob Smith ，您可以快速找到 S 部分，然后 Sm ，然后是所有 Smith < / em>的，然后最终 Bob 。这很快，因为索引中有两个键。由于本书是按姓氏排序的，因此找到所有 Smith 条目也同样简单。

现在想象一下，试图在整个电话簿中找到所有名为 Bob 的人。更难，对吧？

这类似于磁盘上的索引的组织方式。当以(name, page)顺序排序的列表将基本上导致所有行的顺序扫描时，查找具有某个页列的所有行，逐个查找具有该行的任何行< EM>页

有关索引如何工作的详细信息，建议您阅读Use the Index, Luke。

Answer 3

您必须分析将使用此表的查询，并确定查询将使用哪些字段对结果进行排序。您应该索引用于排序最多的字段。

复合键的索引是否足够？

3 个答案: