mysql btrees:当使用所有列时,基数和列顺序对复合索引重要吗?

hof1towb  于 2021-06-20  发布在  Mysql
关注(0)|答案(1)|浏览(383)

我很难弄清楚,所以让我问你。给出以下查询:

select name from users where company_id = ? and creation_date > ?

假设我们只有2家公司,每个公司都有数百万用户在不同的时间创建。所以 creation_date 要高得多。以下哪个索引更快,为什么?
索引a(公司id、创建日期)
索引(创建日期、公司id)
索引c(创建日期)
索引(公司id)
哪个索引更快(或理论上相等)?忽略磁盘空间使用,除非这会影响读取性能。我的想法: (index_b ~= index_c) > index_a > index_d 因为在btree中,“timestamp”将分组在单个区域中,所以获取将提前停止。这个 company_id 实际上并不重要,因为db需要使用索引中的rowid来接触表行以获取数据 name 对于 SELECT . 几乎没有区别。第二名是 index_a 在btree中将一个较低的基数值“分组”在一起,因此“b搜索”需要一些时间来通过限制搜索范围来显示其值 creation_date (位于索引的“尾部”)。最后呢 index_d 更糟的原因很明显(例如一百万行中基数为2)。
bônus问题:如果我们有10kk行,5kk用于公司a和公司b,7kk时间戳平均分布于两个公司,其他3kk完全不同的时间戳呢。7kk范围内的搜索会比3kk范围内的搜索差得多吗?
是这样吗?我错过了什么?
(可视化算法的好地方:https://www.cs.usfca.edu/~galles/visualization/btree.html)
p、 s:stackoverflow中有两个相互矛盾的答案:
mysql复合索引中键的性能排序(wrt rails多态关联和sti)
对于具有不同基数的列的复合索引,顺序是否重要?

83qze16e

83qze16e1#

对于那个特定的查询,索引\u a应该是最快的,因为结果正好对应于索引中的一个范围。
使用索引\u b或索引\u c比较慢。您必须获得有效日期的范围,然后筛选出具有错误公司id的行。在这两个行中,索引c比较慢,因为您必须接触筛选出的行。
使用索引d最慢。您可以找到公司id的范围,但必须扫描所有行以查找匹配的日期。

相关问题