索引和 B 树

数据库如何在几分之一秒内从数百万行中找到一条记录？

默认情况下，当我们请求 SELECT * FROM customers WHERE city = 'Milano' 时，Postgres 必须执行 顺序扫描：它从磁盘中逐行物理读取整个表，将每个城市与“米兰”进行比较。当表包含数百万条记录时，此过程会降低性能。

这些瓶颈的主要结构答案是索引。

索引（B 树）

索引的工作原理与一本大书后面的分析索引完全相同。我们不是阅读整本书来查找其中提到“Milano”的地方，而是查找后面几页，其中“Milano”一词将我们重定向到[p. 45, 114, 230]。 数据库在幕后构建这种独立的、非常紧凑的数据结构（通常是“B 树”），该数据结构按相关列排序，包含指向匹配行的物理存储的直接指针。

-- Creare un indice semplice
CREATE INDEX idx_customers_city ON customers(city);

此单个操作会触发 Postgres 引擎，该引擎将在后台提取所有 city 值并为其建立索引。完成后，后续的每个 SELECT ... WHERE city = '...' 都会飞行！

主键和唯一性

您是否知道主键 (PRIMARY KEY) 和 UNIQUE 键规则在幕后秘密使用索引？由于数据库必须确保在插入或更改行时电子邮件或 ID 永远不会重复，因此 PostgreSQL 会自动在它们之上创建隐式 B 树索引：这样唯一性检查只需几微秒。

这就是为什么 ID 字段上的连接具有令人难以置信的性能。

删除索引

如果您意识到繁重的查询已发生变化并且从未查阅过索引，那么明智的做法是销毁它并回收重要空间：

DROP INDEX idx_customers_city;

轮到你了

探索二级唯一索引