在 web 页面上该如何处理庞大数据的排序？

[skyshy]

数据以表格的形式展示，每页 N （比如 N=20 ）条数据。数据下发：

1. 可以一次性下发给页面，然后前端进行分页，
2. 也可以按每页 20 条，只下发当前页的数据。

数据可以在当前页进行排序，也可以输入数值 （有校验），然后调到数值对应的位置。

普通做法就是以方式 1 的形式，全部下发给页面。用户调整完顺序后，再把全部顺序提交上来。

现在遇到一个问题，面对庞大数据量时，只能下发当前页的数据。此时，如何处理排序？要考虑到跨页排序。

[UIXX]

假设是 BS 架构，考量点有两个：数据类型（分为“可作为热数据处理”与“可作为冷数据处理”） 与 数据量（量级）

为方便叙述，这里假定：
小型数据为计算力正常可处理数据量
中型数据为计算力可处理上限
大型数据为计算力尚未达到的量级

1、小型冷数据
你提供的方案 1、2 都可行，对于方案 1，简单点前端接收作暂时性存储，超时范围内不用再进行收发请求，页面直接排序
2、中型冷数据
方案 1 可行，但不好用，容易引起浏览器性能问题，我们最常用的是 2 按页查询，就是很简单的排序范围查询
3、大型冷数据
方案 1 不可行，只能 2，甚至需要一些其他辅助手段，不详展开

对于热数据，我建议评估一下热数据的类型，处理交易状态类数据跟设备状态类数据是完全不一样的。拿交易状态类举例：

1、小型热数据
选择方案 1，尤其是高频交易，有助于缓解后台部分压力
2、中型热数据
方案 2，优化后端数据库操作
3、大型热数据
方案 1、2 都未必可行，可能需要调整存储策略，此时排序本身并不是重点。（这类大部分都不是 BS 架构的东西）

OK，你的问题可以形象化为假设你有十亿条数的记录，如何显示已排序的某连续 20 个（有可能是中间 20 个）
确认你的排序依据是否可以被序号 hash，如果是，那可以直接 hash 得到。如果否：
首先你得明确，在前端无法获得全量数据的情况下，要得到全局排序序列，必须后端排序，前端获取。也就是你前端的工作只是展示，而不是排序。

-----------------------------假设你寻求的是后端的方案-----------------------------------

0、常规优化
索引与多重索引、读写分离、垂直 /水平分库表、查询缓存...blahblahblah

1、业务降维
细化查询范围、拆分数据结构...blahblahblah

2、查询拆分与查询批处理
这个视业务而定，是一次查询整个序列，还是一次查询其中几个改变的...blahblahblah

[skyshy]

@UIXX 目前遇到的问题是 关于前端排序（不仅仅是升降序，还有调整某些条目之间的顺序），全部下发过去的话，数据量庞大；分页的话，排序也只能在当前页（有多个用户同时调整顺序的情况）