唯一索引是否更适合列搜索性能？（PGSQL 和 MySQL）答案

【问题标题】：Are unique indexes better for column search performance? (PGSQL & MySQL)唯一索引是否更适合列搜索性能？（PGSQL 和 MySQL）
【发布时间】：2010-11-20 13:54:13
【问题描述】：

我很好奇

CREATE INDEX idx ON tbl (columns);

对比

CREATE UNIQUE INDEX idx ON tbl (columns);

在扫描索引列或 UNIQUE 关键字是否仅在索引旁边引入唯一约束时，在 PostgreSQL 或 MySQL 实现中具有显着的算法性能优势。

我想可以公平地说，因为索引很可能在内部实现为某种类似散列¹的结构，并且根据定义进行冲突处理会导致O(1) 性能以外的东西。鉴于此前提，如果大部分值相同，则结构可能会退化为线性。

因此，就我的问题而言，假设值的分布是相对离散且均匀的。

提前致谢！

^{1 这对我来说纯属猜测，因为我不熟悉 RDBM 内部结构。}

【问题讨论】：

标签： postgresql mysql hash indexing

【解决方案1】：

如果您的数据是唯一的，您应该在它们上创建一个UNIQUE 索引。

这意味着没有额外的开销，并且在某些情况下会影响优化器的决策，以便它可以选择更好的算法。

例如，在SQL Server 和PostgreSQL 中，如果您对UNIQUE 键进行排序，优化器将忽略之后使用的ORDER BY 子句（因为它们不相关），即。 e.这个查询：

SELECT  *
FROM    mytable
ORDER BY
        col_unique, other_col
LIMIT 10

将使用col_unique 上的索引，并且不会对other_col 进行排序，因为它没用。

这个查询：

SELECT  *
FROM    mytable
WHERE   mycol IN
        (
        SELECT  othercol
        FROM    othertable
        )

如果othertable.othercol 上有一个UNIQUE 索引，也将转换为INNER JOIN（而不是SEMI JOIN）。

索引总是包含某种指向行的指针（PostgreSQL 中的ctid，MyISAM 中的行指针，InnoDB 中的主键/唯一符）并且叶子在这些指针上排序，所以事实上，每个索引叶在某种程度上都是唯一的（尽管可能并不明显）。

有关性能详情，请参阅我的博客中的这篇文章：

Making an index UNIQUE

【讨论】：

【解决方案2】：

在更新/插入操作期间，由于具有唯一性约束，会有一点小损失。它必须在插入/更新操作之前进行搜索，以确保不违反唯一性约束。

【讨论】：

仅供参考，它必须扫描 btree 才能找到放置索引数据的页面，所以这几乎是一个清洗。

【解决方案3】：

嗯，通常索引是 B 树，而不是哈希（有基于哈希的索引，但最常见的索引（至少在 PostgreSQL 中）是基于 B 树的）。

至于速度-唯一性应该更快-当索引扫描找到具有给定值的行时，它不必搜索是否有任何其他具有该值的行，并且可以立即完成扫描。

【讨论】：