这是一个创建于 2565 天前的主题，其中的信息可能已经有所发展或是发生改变。
对于 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 建立单列索引来查询
在索引的体积和查询性能上考虑，能有提升么？有的话多大效果？
 |
1
akira 2017-12-21 01:19:42 +08:00
要相信数据库的优化
|
 |
2
stabc 2017-12-21 01:44:35 +08:00
>一种是 sort 里存值的时候，值设计成直接是 sort*10^N + id (评估位数决定 N)，这样 sort 就也是 unique 了，对 sort 建立单列索引来查询
推荐这种方式，想法也很聪明。第一种方式有不确定性。 |
 |
3
samuel 2017-12-21 01:48:49 +08:00
如果 sort 的基数比 id 小很多，那么建一个(id, sort)的多列索引，应该会快些吧。若非不得已不要用方案二，它引入了额外的函数依赖，对于以后的维护不利。
ps：为啥不直接测试一下呢。 |
 |
6
hheedat OP @samuel sort 的区分度是比 id 要小一些，不过要先按照 sort 排序，建立（ id，sort ）恐怕是没有用
|
 |
7
whx20202 2017-12-21 10:39:43 +08:00
如果是 mysql 的 innodb，因为是索引组织表，order by sort 默认就是 order by sort,id 把？
如果我没记错的话 |
 |
8
yujieyu7 2017-12-21 12:05:11 +08:00
不建议第二种
以后 id 会涨到多少不好预估，那现在设计的时候 sort*10^N 里的 N 就很难设置一个合理的值吧，而且这么一来 sort 字段的长度也上去了，最后下来的索引体积不见得比复合索引会小 主要这种做法很不合逻辑，以后有新需求也不好扩展 |
Select Language