这是一个创建于 2872 天前的主题，其中的信息可能已经有所发展或是发生改变。
对于 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