问题背景

MySql(InnoDB)中的订单表需要按时间顺序分页查询,且主键不是时间维度递增,订单表在百万以上规模,此时如何高效地实现该需求?

注:本文并非主要讲解如何建立索引,以下的分析均建立在有合适的索引的前提下

初步方案1

众所周知,MySql中,有一个limit offset, pageSize的用法,可以实现分页查询

select * from order where user_id = xxx and 【其它业务条件】 order by created_time, id limit offset, pageSize

因为created_time可能重复,所以order by时应加上id,保证顺序的确定性

点评

该方案在表规模较小的时候,不会暴露出问题,当order表增长到十万级,并且查询后面几页的时候,执行速度明显变慢,可能降到100ms的量级,如果数据量增长到百万级,则耗时达到秒级,如果增长到千万级,那耗时就变得完全不可接受了(曾排查过这样的线上慢SQL)


深入分析

方案1为啥在大表中表现这么差呢?我们可以来揣测一下MySql是怎么执行这个查询的

假设我们在user_id,created_time,以及【其它业务条件】建立了联合索引,当我要查找第100000条到100049条的记录时,因为MySql的索引是b+ tree结构,不像数组可以随机定位到第N条记录,它需要花不小的成本去找到N的位置,N越大,成本越大

抛开b+ tree的细节不讲,我们还可以借助统计表记录总数的SQL来理解

select count(1) from order

如果能非常高效地定位第N条记录,那么上述统计也能非常高效的执行,但实际上,在大表中统计记录总条数,也是非常慢的(本文是在InnoDB的场景下)

方案1低效的根本原因在于:定位到offset的成本过高,未能充分利用索引的有序性


方案2

索引(b+ tree)的特点在于,数据是有序的,虽然找到第N条记录的效率比较低,但找到某一条数据在索引中的位置,其效率是很高的(索引本来就是解决这个问题的)

我们换一种思路,每次取50条记录,第一次取的时候,指定从上次结束的位置继续往后取50条,这样,我们便可以利用上索引的有序性了

我们先看一个以id为序,进行分页查询的例子

select * from order where id > 'pre max id' order by id limit 50

第一次查询不用带条件,后续查询则传入前一次查询的最大id,简单分析可知,MySql在执行时,先定位到pre max id的位置(id是有序的,定位非常快),然后从这往后取50条记录即可,整个过程非常高效

我们回到最开始的问题,“按时间顺序分页查询,且主键不是时间维度递增”,此时我们不能用id作为分页的条件,因为按它去分页,便不是按时间顺序了,但也不能直接把id换成时间,因为时间可能会重复,我们来分析一下

id username created_time
xxx zhangsan 2019-01-01
ddd zhangsan 2019-02-03
yyy zhangsan 2019-02-03
abc zhangsan 2019-02-05
aaa zhangsan 2020-08-01

假如前一次分页的最后一条记录为id=ddd的这条(created_time为2019-02-03),下一次查询使用created_time>2019-02-03作为条件时,则会把id=yyy的这条记录漏掉,如果换成created_time>=2019-02-03也不行,id=ddd的这条记录就又被查出来了

对于这个数据遗漏或重复的问题,我看到一种解决方案是这样的:

分三种情况进行查询

  1. 首次查询,created_time>='xxxx-xx-xx',如果不要求以某时间开始,则无条件

    select * from order where user_id = xxx and 【其它业务条件】 and created_time >= 'xxxx-xx-xx' order by created_time, id limit pageSize
  2. 如果上次查询的记录条数等于pageSize,则用created_time和id的组合条件来查询,为了防止created_time在边界位置发生重复时漏掉数据
    select * from order where user_id = xxx and 【其它业务条件】 and created_time = 'created_time of latest recored' and id > 'id of latest recored' order by created_time, id limit pageSize
  3. 如果上次查询的记录数小于pageSize,并且上次查询是第二种查询,则仅用created_time来查询,
    select * from order where user_id = xxx and 【其它业务条件】 and created_time > 'created_time of latest recored' order by created_time, id limit pageSize

点评

上述方法确实可以解决漏掉数据或重复的问题,并且也有着不错的性能,但缺点也比较明显,查询过于复杂,得分情况执行不同的SQL,并且分页不稳定,中间查询出来的记录数可能小于pageSize,实际上后面还有数据


进一步深入分析

我尝试在网上找过资料,只找到了以id为分页顺序,然后用id>'pre max id'这种方式来查,而我们要以可重复的created_time为分页顺序,如何写出简洁高效的SQL呢?

如果要成为一个优秀的程序员,我觉得分析&解决新问题的能力,是必不可少的,即使在网上能找到解决方案,优秀的分析能力也有助于借鉴并结合自己的场景,优化出更好的个性化方案。

我们在(user_id,created_time)建立了索引,并且我们知道InnoDB的辅助索引是包含了主键的,且主键一定不会重复,这意味着在索引上,每条记录的顺序是完全确定的,不存在重复的情况

我们要分页的顺序跟此索引的顺序是吻合的,只需要沿着索引,一批一批地取数据就可以了,这是一个对索引很直接的利用,为什么现在我没办法做到?

如果我是MySql的设计人员,针对这种很常见很直接的需求,我怎么去提供支持?还是说不支持?

我举一个例子,像java中的基于排序的TreeSet,我猜它一定有floor和ceiling这样的方法(返回Set中,大于或小于指定元素的第一个元素),这是基于排序的数据结构该有的东西,如果它没有,那早被人喷了然后加上去了

回到索引的话题,这种直接的需求,它应该支持,否则说不过去,现在的问题变成了:用什么语法来,来实现在组合索引上,基于组合(user_id,created_time,id的组合)顺序的遍历?

此时脑海里便回想起以前用过的(a,b) in ((1,2),(3,4),(7,4))这样的组合写法,然后猜测它也支持大于小于这类比较,跑去MySql中验证一下:

select (3,7)>(3,7),    (3,6)>(3,7),    (3,8)>(3,7),    (4,7)>(3,7),    (4,2)>(3,7);
返回:
0 0 1 1 1

如此一来,这问题就变得和id>'pre max id'这种一样简单了。

注:这种写法后来在官方文档中找到了对应的资料,官方称这类运算为“行比较”(row comparisons)

https://dev.mysql.com/doc/refman/5.7/en/comparison-operators.html#operator_greater-than

方案3

由于有(a,b)>(1,2)这种语法,所以可以写出简洁又高效的SQL

select * from order where user_id = xxx and 【其它业务条件】 and (created_time, id) > (created_time and id of latest recode) order by created_time, id limit pageSize

此方式跟以id为序的分页查询是一样的,首次查询去掉组合条件即可,代码简洁,同时又可以利用上组合索引,十分高效,耗时稳定,不会因为遍历到末尾而性能降低


总结

方案1在小表的情况下,简单方便,只用传页码和页大小即可,还可以随机跳到指定页,具有一定优势

方案2和方案3在大表的情况下,有着优异的性能,以及稳定性,缺点是不能随机地跳转页面,需要传入上一页的排序字段。这个弊端在一定程度上可以规避,比如现在很多分页都是一页一页地往下翻,比如微博、朋友圈动态等,或者是分批处理全表数据,不需要随机跳转

细心的同学可能发现,where条件里还有【其它业务条件】,这样还能正常走索引吗?是否会发生全表扫描?这个问题其实是可以规避的,有空再写一篇执行计划并不完全可靠的案例。

题外话

方案3的写法是我自己琢磨出来的,在网上也没找到类似的资料,算独门秘技吧,除此之外,我觉得同样很有价值的是【进一步深入分析】中的思考过程,如果养成这种思考习惯,有利于创新,去解决别人没遇到过的问题,在未知的领域,知道该从哪个方向去寻找答案;或者找到新的方法更好地去解决旧问题。

如果本文有帮助到你,或者觉得有价值,麻烦点个赞,这样我会更有动力去更多地分享自己的经验

MySql大表分页(附独门秘技)的更多相关文章

  1. 优秀后端架构师必会知识:史上最全MySQL大表优化方案总结

    本文原作者“ manong”,原创发表于segmentfault,原文链接:segmentfault.com/a/1190000006158186 1.引言   MySQL作为开源技术的代表作之一,是 ...

  2. MySQL 大表优化方案(长文)

    当MySQL单表记录数过大时,增删改查性能都会急剧下降,可以参考以下步骤来优化: 单表优化 除非单表数据未来会一直不断上涨,否则不要一开始就考虑拆分,拆分会带来逻辑.部署.运维的各种复杂度,一般以整型 ...

  3. [记录]一则清理MySQL大表以释放磁盘空间的案例

    一则清理MySQL大表以释放磁盘空间的案例 一.基本情况: 1.dbtest库554G,先清理st_online_time_away_ds(37G)表的数据,保留半年的数据: 1)删除的数据:sele ...

  4. 从云数据迁移服务看MySQL大表抽取模式

    摘要:MySQL JDBC抽取到底应该采用什么样的方式,且听小编给你娓娓道来. 小编最近在云上的一个迁移项目中被MySQL抽取模式折磨的很惨.一开始爆内存被客户怼,再后来迁移效率低下再被怼.MySQL ...

  5. MySQL大数据分页的优化思路和索引延迟关联

    之前上次在部门的分享会上,听了关于MySQL大数据的分页,即怎样使用limit offset,N来进行大数据的分页,现在做一个记录: 首先我们知道,limit offset,N的时候,MySQL的查询 ...

  6. 详解MySQL大表优化方案( 转)

    当MySQL单表记录数过大时,增删改查性能都会急剧下降,可以参考以下步骤来优化: 单表优化 除非单表数据未来会一直不断上涨,否则不要一开始就考虑拆分,拆分会带来逻辑.部署.运维的各种复杂度,一般以整型 ...

  7. MySQL 大表优化方案探讨

    当MySQL单表记录数过大时,增删改查性能都会急剧下降,可以参考以下步骤来优化: 单表优化 除非单表数据未来会一直不断上涨,否则不要一开始就考虑拆分,拆分会带来逻辑.部署.运维的各种复杂度,一般以整型 ...

  8. MySQL大表优化方案

    转:https://segmentfault.com/a/1190000006158186?hmsr=toutiao.io&utm_medium=toutiao.io&utm_sour ...

  9. MySQL 大表优化方案

    当MySQL单表记录数过大时,增删改查性能都会急剧下降,可以参考以下步骤来优化: 单表优化 除非单表数据未来会一直不断上涨,否则不要一开始就考虑拆分,拆分会带来逻辑.部署.运维的各种复杂度,一般以整型 ...

随机推荐

  1. Serverless介绍篇(一)云开发在Serverless方面取得了怎样的新成果?

    过去几年间,Serverless 发展迅猛,与其相伴的还有从小程序.移动端等到前后端一体化的演进与实践,也正因如此,从云计算到前端,众多开发者都极为关注.本文介绍了腾讯云CloudBase 的 Ser ...

  2. 从0开始,手把手教你使用React开发答题App

    项目演示地址 项目演示地址 项目源码 项目源码 其他版本教程 Vue版本 小程序版本 项目代码结构 前言 React 框架的优雅不言而喻,组件化的编程思想使得React框架开发的项目代码简洁,易懂,但 ...

  3. java IO流 (二) IO流概述

    1.流的分类* 1.操作数据单位:字节流.字符流* 2.数据的流向:输入流.输出流* 3.流的角色:节点流.处理流 图示: 2.流的体系结构 说明:红框对应的是IO流中的4个抽象基类.蓝框的流需要大家 ...

  4. java 面向对象(七):类结构 方法(四)递归方法

    1.定义:递归方法:一个方法体内调用它自身.2.如何理解递归方法?> 方法递归包含了一种隐式的循环,它会重复执行某段代码,但这种重复执行无须循环控制.> 递归一定要向已知方向递归,否则这种 ...

  5. XSS原理及代码分析

    前言 XSS又叫跨站脚本攻击,是一种对网站应用程序的安全漏洞攻击技术.它允许恶意用户将代码注入网页,其他用户在浏览网页时就会受到影响.XSS分为三种:反射型,存储型,和DOM型.下面我会构造有缺陷的代 ...

  6. Odoo13之在tree视图左上角添加自定义按钮

    前言 首先展示效果图,如下图所示,在资产设备模块tree视图的左上角添加了一个同步资产的按钮. 要完成按钮的添加,分为四步,分别是: 1.编写xml文件,找到相关模型tree视图,并给模型tree视图 ...

  7. mysql实现主从复制/主从同步

    业务场景 小公司业务代码存于一个服务器上,而这个服务器有的时候回宕机,导致业务停顿,造成影响.这个时候 就需要做高可用 两个ngix+两个tomcat+两个mysql实现高可用,避免单点问题.中间使用 ...

  8. 机器学习实战---决策树CART回归树实现

    机器学习实战---决策树CART简介及分类树实现 一:对比分类树 CART回归树和CART分类树的建立算法大部分是类似的,所以这里我们只讨论CART回归树和CART分类树的建立算法不同的地方.首先,我 ...

  9. day8 python 列表,元组,集合,字典的操作及方法 和 深浅拷贝

    2.2 list的方法 # 增 list.append() # 追加 list.insert() # 指定索引前增加 list.extend() # 迭代追加(可迭代对象,打散追加) # 删 list ...

  10. linux目录结构 主流Linux发行版的目录结构

    目录 目录结构 一般教学的目录 CentOS7 openSUSE15.1 Ubuntu18.04 详细说明: /dev目录 /etc目录 /proc目录 /usr目录 /var目录 比较重要的目录 文 ...