这是一个创建于 2145 天前的主题，其中的信息可能已经有所发展或是发生改变。
数据以表格的形式展示，每页 N （比如 N=20 ）条数据。数据下发：
- 可以一次性下发给页面，然后前端进行分页，
- 也可以按每页 20 条，只下发当前页的数据。
数据可以在当前页进行排序，也可以输入数值 （有校验），然后调到数值对应的位置。
普通做法就是以方式 1 的形式，全部下发给页面。用户调整完顺序后，再把全部顺序提交上来。
现在遇到一个问题，面对庞大数据量时，只能下发当前页的数据。此时，如何处理排序？要考虑到跨页排序。
 |
1
UIXX 2019-01-11 13:50:38 +08:00  1
假设是 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 |
Select Language