大表分页查询非常慢，怎么办？
发布时间：2022-08-02 11:11:54 所属栏目：云计算 来源：互联网
导读：一、问题复现 在实际的软件系统开发过程中，随着使用的用户群体越来越多，表数据也会随着时间的推移，单表的数据量会越来越大。 以订单表为例，假如每天的订单量在 4 万左右，那么一个月的订单量就是 120 多万，一年就是 1400 多万，随着年数的增加和单日下
|
一、问题复现 在实际的软件系统开发过程中，随着使用的用户群体越来越多，表数据也会随着时间的推移，单表的数据量会越来越大。 以订单表为例，假如每天的订单量在 4 万左右，那么一个月的订单量就是 120 多万，一年就是 1400 多万，随着年数的增加和单日下单量的增加，订单表的数据量会越来越庞大，订单数据的查询不会像最初那样简单快速，如果查询关键字段没有走索引，会直接影响到用户体验，甚至会影响到服务是否能正常运行！ 下面我以某个电商系统的客户表为例，数据库是 Mysql，数据体量在 100 万以上，详细介绍分页查询下，不同阶段的查询效率情况（订单表的情况也是类似的，只不过它的数据体量比客户表更大）。 下面我们一起来测试一下，每次查询客户表时最多返回 100 条数据，不同的起始下，数据库查询性能的差异。 当起点位置在 0 的时候，仅耗时：18 ms 当起点位置在 1000 的时候，仅耗时：23 ms 当起点位置在 10000 的时候，仅耗时：54 ms 当起点位置在 100000 的时候，仅耗时：268 ms 当起点位置在 500000 的时候，仅耗时：1.16 s 当起点位置在 1000000 的时候，仅耗时：2.35 s 可以非常清晰的看出，随着起点位置越大，分页查询效率成倍的下降，当起点位置在 1000000 以上的时候，对于百万级数据体量的单表，查询耗时基本上以秒为单位。 而事实上，一般查询耗时超过 1 秒的 SQL 都被称为慢 SQL，有的公司运维组要求的可能更加严格，比如小编我所在的公司，如果 SQL 的执行耗时超过 0.2s，也被称为慢 SQL，必须在限定的时间内尽快优化，不然可能会影响服务的正常运行和用户体验。 对于千万级的单表数据查询，小编我刚刚也使用了一下分页查询，起点位置在 10000000，也截图给大家看看，查询耗时结果：39 秒！ 没有接触过这么大数据体量的同学，可能多少对这种查询结果会感到吃惊，事实上，这还只是数据库层面的耗时，还没有算后端服务的处理链路时间，以及返回给前端的数据渲染时间，以百万级的单表查询为例，如果数据库查询耗时 1 秒，再经过后端的数据封装处理，前端的数据渲染处理，以及网络传输时间，没有异常的情况下，差不多在 3～4 秒之间，可能有些同学对这个请求时长数值还不太敏感。 据互联网软件用户体验报告，当平均请求耗时在1秒之内，用户体验是最佳的，此时的软件也是用户留存度最高的；2 秒之内，还勉强过的去，用户能接受；当超过 3 秒，体验会稍差；超过 5 秒，基本上会卸载当前软件。 有的公司为了提升用户体验，会严格控制请求时长，当请求时长超过 3 秒，自动放弃请求，从而倒逼技术优化调整 SQL 语句查询逻辑，甚至调整后端整体架构，比如引入缓存中间件 redis，搜索引擎 elasticSearch 等等。 继续回到我们本文所需要探讨的问题，当单表数据量到达百万级的时候，查询效率急剧下降，如何优化提升呢？ 二、解决方案 下面我们一起来看看具体的解决办法。 1. 方案一：查询的时候，只返回主键 ID 我们继续回到上文给大家介绍的客户表查询，将select *改成select id，简化返回的字段，我们再来观察一下查询耗时。 当起点位置在 100000 的时候，仅耗时：73 ms （编辑：岳阳站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐
热点阅读
