写点什么

大量数据如何做分页处理

  • 2024-04-10
    广东
  • 本文字数:2143 字

    阅读完需:约 7 分钟

大量数据如何做分页处理

本文分享自华为云社区《应用中大量数据的分页处理》,作者:码乐。

简介


大批量数据的展示一直被视为一个必须要解决的问题。 一个经典的思想就是分批展示和处理它们。

1 查询时外键的处理


如果在 django model 中模型使用了外键,通过 on_delete 来定义关联操作。


CASCADE: 级联操作。如果外键那条数据删除了,这条数据也将被删除PROTECT: 受保护,只要这条数据引用了外键的那条数据,旧不能删除外键数据,如果强行删除,Django框架将报错SET_NULL: 设置为空,如果外键数据被删除,本条数据设置为空,前提是 可以设置本条数据为空SET_DEFAULT: 设置默认值,如果外键数据删除了,设置这个数据的值为默认,前提是有默认值SET()函数: 如果外键那条数据被删除,那么将会获取SET函数的值作为外键的值。Set()函数可以接受可调用对象,可调用对象的返回值作为结果设置回去。DO_NOTHING: 不采取任何行为,一切看数据库级别的行为。
复制代码


数据库层面的约束:


PESTRICT: 默认选项,如果要删除父表记录,如果子表有关联记录,则不允许删除NOACTION:同上,首先检测外键CASCADE: 父表delete,update时,子表关联操作 也进行 delete,updateSET NULL:父表delete , update时,子表将关联记录外键字段设置为null,所以设计子表时不能 not null
复制代码


这些外键的方法工具,可以帮助使用者处理多表关联查询任务。


1.1 如何在 django 中查询分页在有分页查询的应用中,包括 LIMIT 和 OFFSET 的查询十分常见,而且几乎每个都会有一个 ORDER BY 子句。


如果使用索引排序的话将对性能优化十分有帮助,否则服务端需要做很多文件排序。


一个高频的问题是 offset 的值过大。如果查询类似 LIMIT 10000, 20,将会产生 10020 行,并将之前的 10000 行丢弃,这样的代价很高。


	select * from table order by id limit 10000, 20;
复制代码


很简单,该语句的意思就是查询 10000+20 条记录,去掉前 10000 条,返回后 20 条。无疑该查询能够实现分页,但 10000 这位置的值越大,查询性能就越低,因为 MySQL 需要扫描全部 10000+20 条记录。


假设所有的页使用相同的频次访问,这样的查询将平均扫描一半数据表。为了优化他们,你可以在分页视图中限制最多可访问的页数,或者让大批量的查询更有效。


当一个表中有很多符合查询条件的数据的时候,我们往往不需要把他们全部一次性取出来,那样对查询效率或者服务器性能来说都会是一个极大的挑战:例如最简单的商城,假设商城中有一万个数据,但我们在前端可能只会每次看到一页.


select * from table where xxx="xxx" limit 10; 
复制代码


这表示查询符合条件的 10 个数据。


select * from table where xxx="xxx" limit 10 offset 10;
复制代码


这表示分页,查询符合条件的第 11 到 20 的数据。


或者通过指定最大 id 去查询


select * from table where id > #max_id# order by id limit n;
复制代码


该查询同样会返回后 n 条记录,却无需像方式 1 扫描前 m 条记录,但必须在每次查询时拿到上一次查询(上一页)的最大 id(或最小 id),是比较常用的方式。


当然该查询的问题也在于,如果最大 id 不是连续的,则我们不一定能拿到这个 id,比如当前在第 3 页,需要查询第 5 页的数据,就不行了。


或者通过子查询,先筛选前 10000 个,找到最大 id,然后选择剩余的 20 个符合要求的


select * from table where id > (select id from table order by id limit m, 1) limit n;
复制代码


该查询同样是通过子查询扫描字段 id, 因为它不需要进行表的关联,而是一个简单的比较,在不知道上一页最大 id 的情况下,是比较推荐的用法。


左右连接的方式本身性能可能更差。还有如下子查询、连接表,加索引快速定位元组,然后再读取元组


SELECT * FROM table WHERE id <= (SELECT id FROM table ORDER BY id DESC LIMIT (page-1)*pagesize ORDER BY id DESC LIMIT pagesize)
复制代码


rest_framework 内建了分页的操作模块,让我们来应用到具体函数即可 employee/views.py


from rest_framework.pagination import PageNumberPagination@api_view(['GET', 'POST']) @permission_classes([CustomPermission])def blog_api_view(request):    """"""    if request.method == "GET":		paginator = PageNumberPagination()        # paginator.page_size = 1 setting we display only 1 item per page.        paginator.page_size = 2        task_objects = EmployeeSign.objects.all()        result = paginator.paginate_queryset(task_objects, request)
复制代码


如果不使用分页,将显示全部的消息在同一个页面


    serializer = TaskSerializer(result, many=True)    return Response(serializer.data)
复制代码


访问分页数据.默认接口http://127.0.0.1:2001/api/tasks/ 就是分页 1


http://127.0.0.1:2001/api/tasks/?page=1  #2,3,4...
复制代码

2 小结


再重复一次,在有分页查询的应用中,包括 LIMIT 和 OFFSET 的查询十分常见,而且几乎每个都会有一个 ORDER BY 子句。如果使用索引排序的话将对性能优化十分有帮助,否则服务端需要做很多文件排序。

一个高频的问题是 offset 的值过大。如果查询类似 LIMIT 10000, 20,将会产生 10020 行,并将之前的 10000 行丢弃,这样的代价很高。


假设所有的页使用相同的频次访问,这样的查询将平均扫描一半数据表。


为了优化他们,你可以在分页视图中限制最多可访问的页数,或者让大量的查询更有效。


点击关注,第一时间了解华为云新鲜技术~

发布于: 刚刚阅读数: 3
用户头像

提供全面深入的云计算技术干货 2020-07-14 加入

生于云,长于云,让开发者成为决定性力量

评论

发布
暂无评论
大量数据如何做分页处理_开发_华为云开发者联盟_InfoQ写作社区