(MongoDB | MySQL）把复合索引合并到单列有意义吗？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

已注册用户请登录

这是一个创建于 2319 天前的主题，其中的信息可能已经有所发展或是发生改变。

对于 mongo 和 mysql，这个问题应该是一样的，应该都是 B* tree，多列索引的存放都是（ fieldA，fieldB，fieldC ）

现在有一个（ collection|table ）

{
id
sort
fieldA
fieldB
...
fieldZ
}

query?last_sort_value={$sort}&last_id={$id}
or
query?last_sort_value={$sort}

查询这个列表，按照 sort 排序，sort 值相同的，按照 id 大小排序，id 为 unique

一种是按照（ sort，id ）建立复合索引查询

一种是 sort 里存值的时候，值设计成直接是 sort*10^N + id (评估位数决定 N)，这样 sort 就也是 unique 了，对 sort 建立单列索引来查询

在索引的体积和查询性能上考虑，能有提升么？有的话多大效果？

thx

sort

索引

MySQL

query

10 条回复 • 2017-12-25 17:38:46 +08:00

akira

2017-12-21 01:19:42 +08:00

要相信数据库的优化

stabc

2017-12-21 01:44:35 +08:00

>一种是 sort 里存值的时候，值设计成直接是 sort*10^N + id (评估位数决定 N)，这样 sort 就也是 unique 了，对 sort 建立单列索引来查询
推荐这种方式，想法也很聪明。第一种方式有不确定性。

samuel

2017-12-21 01:48:49 +08:00

如果 sort 的基数比 id 小很多，那么建一个(id, sort)的多列索引，应该会快些吧。若非不得已不要用方案二，它引入了额外的函数依赖，对于以后的维护不利。

ps：为啥不直接测试一下呢。

hheedat

2017-12-21 10:07:50 +08:00

@samuel 我今天测试一下

hheedat

2017-12-21 10:12:11 +08:00

@stabc 您说的不确定性是指？

hheedat

2017-12-21 10:15:13 +08:00

@samuel sort 的区分度是比 id 要小一些，不过要先按照 sort 排序，建立（ id，sort ）恐怕是没有用

whx20202

2017-12-21 10:39:43 +08:00

如果是 mysql 的 innodb，因为是索引组织表，order by sort 默认就是 order by sort,id 把？

如果我没记错的话

yujieyu7

2017-12-21 12:05:11 +08:00

不建议第二种

以后 id 会涨到多少不好预估，那现在设计的时候 sort*10^N 里的 N 就很难设置一个合理的值吧，而且这么一来 sort 字段的长度也上去了，最后下来的索引体积不见得比复合索引会小

主要这种做法很不合逻辑，以后有新需求也不好扩展

hheedat

2017-12-25 17:30:40 +08:00

@whx20202 是 sort，id，但这是使用表现，你不把 id 建到索引里对 id 的排序不会用到索引

hheedat

2017-12-25 17:38:46 +08:00

@stabc
@samuel
我今天测试了一下，500w 条数据，分别查询 5w 次； 1，2 对索引的大小，几乎没有任何影响；
对单条的查询速度，第 1 种稍微慢点。
但是第一种查询在业务上不能单写成 {$sort:{$lt:$last_sort},$_id:{$lt:last_id}},而要写成 {$or:[{$sort:$lte:$last_sort,$_id:{$lt:$last_id}},{$sort:{$lt:$last_sort}}]} ，用了$or 之后，速度上会有百倍的差距。