主页 / dba / 问题 / 174227
Accepted
ivan
Asked: 2017-05-23 06:48:17 +0800 CST

复合索引中的基数和列顺序 (MySQL/InnoDB)

  • 772

我知道如果您想按索引列的子集进行查询，复合索引中的列顺序很重要，但是如果您查询指定所有索引列的值，那么拥有高基数列是否有任何性能优势早于低基数列？我依稀记得读过一些建议是这种情况的东西，因为它可以更快地缩小结果集，但我现在找不到任何东西来支持它。

我正在使用带有 InnoDB 的 MySQL。InnoDB 使用聚集索引，这可能与我的问题相关，但我认为它只对主键这样做，而我的索引不是。该表看起来像这样：

CREATE TABLE `my_table` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `ref_a_id` int(10) unsigned NOT NULL,
  `ref_b_id` int(10) unsigned NOT NULL,
  `is_active` tinyint(1) DEFAULT '1',
  PRIMARY KEY (`id`),
  UNIQUE KEY `index_my_table_on_ref_a_ref_b_is_active` (`ref_a_id`, `ref_b_id`, `is_active`)
) ENGINE=InnoDB AUTO_INCREMENT=2818259 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci

关于我的问题， imagineref_a_id的基数比ref_b_id.

mysql index

1 个回答

  1. Best Answer

    基数很重要是老太太的故事。

    INDEX(a,b)并且INDEX(b,a)在 BTree 中执行几乎相同。BTree 的深度是相同的。

    重要的是两列都用 搜索=，如WHERE a=12 AND b=45。

    InnoDB中的PRIMARY KEY是BTree，各个二级索引也是。唯一的区别是叶节点中还有什么。PK的叶节点包含所有列；二级索引的叶节点包含 PK 的列。

    在 InnoDB 中（不是在某些竞争产品中），根据定义，PK 是集群和UNIQUE.

    至于你的桌子，...

    您是否允许每个 ref_a--ref_b 组合的行？一个“活跃”，一个不活跃？这似乎不太可能。

    为什么有id呢？为什么不提升UNIQUE关键是PK？

    is_active曾经吗NULL？

    请参阅我关于许多：许多映射表的提示。

    • 3

相关问题