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

[hheedat]

对于 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 建立单列索引来查询

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

[akira]

要相信数据库的优化

[stabc]

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

[samuel]

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


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

[hheedat]

@samuel 我今天测试一下

[hheedat]

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

[hheedat]

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

[whx20202]

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

如果我没记错的话

[yujieyu7]

不建议第二种

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

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

[hheedat]

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

[hheedat]

@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 之后，速度上会有百倍的差距。