这个就是方案设计有问题了,不管是什么情况下,什么场景,都不应该一次输出这么多的数据吧
历史订单查询,三个月的销售记录就有这么多 12w左右
@阿旭。: 还是设计有问题啊,实在想导出那么多数据,可以分页读取啊,每次读个几百条
@jqw2009: 分页不过是前端内边就是渲染速度可慢
@阿旭。: 这个要看怎么分页了,一个是加分页的sql语句,这样查出来的就只有几百条,一个是全部都查出来然后在前端做缓存分页,你这么多数据,只能是后台数据库那边就要分页查询了
就好比一个假分页(前端),一个是真分页(数据库)
@jqw2009: 感觉还是不行,他要直接导出excel表还得前端全部分页渲染
这设计有问题,哪有一次性渲染上万条数据的,不合理
而且一页也显示不全吧,分页不好吗?
@人间春风意: 前端内边分页了但是加载还是会卡
@阿旭。: 当然会卡,上万条数据,切割,获取指定下标范围内的数据量,
@阿旭。: 你可以本地试一下,前端定死10000+数据,切割分页数量,纯前端都会卡,
如果非要后端一下子全返回,
可以让后端返回数据的时候,
返回一个数组,
到时候前端绑定数据,使用xxxData[pageNum]
的方式,应该会比直接上万的数组切割好点,
可以把后端返回的数据结构范例贴一下吗?
@人间春风意:
具体数据在data里
@阿旭。: data里10万+?crazzy
@人间春风意: 现在没有 以后可能会有
@人间春风意: 如果有的话怎么处理呢
@阿旭。: 最好每页动态请求,这是最好的情况和方案
如果接口必须返回10万+数据,
那就在data里返回数组,就类似这种,这种就是矮子里挑将军,使用这种,
data[
[{},{},{},...],// 10条或更多条
[{},{},{},...]
]
这个时候,取第一页数据 data[0]的数据绑定
如果data[0]里有100条数据,可以100条数据取20~30数据
@人间春风意: 前端好处理吗这样
@阿旭。: 不好,建议后端,后端实在不行,比如后端跑了或者后端不愿意修改,那就只能前端搞了
1,分页返回数据
2,如果要导出excel表,可以在服务器上生成excel,然后把文件返回给客户端。不过你说有几十万行,excel里也放不了这么多行吧。