mysql - 多列索引比单列索引慢吗？

Question

我有一个关于(A, B)where Ais anINT和Bis an的主键INT。如果我有一个索引，搜索查询会A运行得更快A吗？

我了解最左边的前缀规则，但我很好奇多列键/索引是否由于键更长而比单列键/索引更差。

Answer 1

在某些情况下，它的性能可能会更差 - 如果其余列很大，例如：A: int, B: varchar(128), C: A 上的文本索引将比 A、B、C 上的索引执行得更好

在大多数情况下，它的表现相同；在您的情况下，您有 4 对 8 个字节，因此拥有第二个索引的开销不值得这样做。

请记住，主键比二级索引执行得更好，特别是如果存储引擎是 InnoDB（主键是集群索引）并且它不是覆盖查询（它必须访问表以加载未存储在索引中的数据)

实际上，在 InnoDB 中，所有二级索引都包含主键，因此默认情况下它们大于 PK。

Answer 2

您遇到复合键有两个组件的情况。第一个是 4 个字节，第二个是 4 个字节。总密钥为 8 个字节。

主键索引是聚集的，这意味着 b 树的“叶子”是实际的记录本身。聚集索引将比其他类型的索引更快地访问。

索引性能的一个考虑因素是键的大小（以及索引中保留的其他列）。具有 4 字节键的索引将小于具有 8 字节键的索引。这意味着更少的磁盘使用和更少的内存存储。但是，这里的收益可能很小。毕竟，表中的一百万行最多对应 10-20 百万个字节（索引中有额外的开销）。

另一个考虑因素是数据修改步骤的性能。在聚集索引中，在表中间插入/修改键值需要自己重写记录。但是，您的问题似乎不是地址数据修改。

如果您已经定义了主键索引，那么添加另一个索引是系统的额外开销。您可能会发现两个索引都在占用内存，因此您实际上不是在节省空间，而是在向它添加。

最终，这类相当神秘的问题的答案是进行一些时序测试。如果B列比组件大得多A，我可能会看到一些收益。对于仅使用的查询A，我可能会看到一些收获。但是，我的猜测是，这样的收益将非常小。