MySQL 千万数据量深分页优化，微服务架构技术栈

最新推荐文章于 2024-08-02 10:30:00 发布
最新推荐文章于 2024-08-02 10:30:00 发布
阅读量278 收藏
点赞数
分类专栏： 程序员 文章标签： 面试 java 后端
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/m0_64205605/article/details/121356415
版权

我们每一次对数据记录的改动，MySQL都会记录一条日志，我们把它称作undo日志，每一条undo日志对应着也都有一个roll_pointer属性（insert操作对应的undo日志没有该属性，因为该记录并没有更早的版本），可以将这些undo日志都连起来，串成一个链表，所以现在的情况就像下图一样：

image.png

对这条记录每次更新后，都会将旧记录放入到undo日志中，就算是该记录的一个历史版本，随着更新次数的一次次增加，所有的版本都会被roll_pointer属性连接成一个链表，我们把这个链表称之为【版本链】，版本链的头节点就是当前记录最新的值。另外，每个版本中还包含生成该版本时对应的事务id，这个ID（事务ID）非常重要，后续事务的隔离级别实现原理都是围绕这个ID（事务ID）来的。

ReadView

** 对于使用【读未提交READ_UNCOMMITTED】这种隔离级别的事务来说，直接读取记录的最新版本就好了，对于使用【串行化SERIALIZABLE】隔离级别的事务来说，使用加锁的方式来访问记录。对于使用【读已提交READ COMMITTED】和【可重复读REPRATABLE_READ】隔离级别的事务来说，就需要用到我们上边所说的【版本链】了，核心的问题就是：我们需要判断版本链中的数据，哪个版本是当前事务可见的。所以设计MySQL官方提出了一个ReadView的概念，这个ReadView中主要包含当前MySQL中还有哪些活跃的读写事务，把它们的事务id放到一个列表中，我们把这个列表命名为为m_ids(一个数组)。这样在我们访问某一条记录时，只需要按照下边的步骤判断记录的某个版本是否可见（官方设计规则哦）：

  • 如果被访问版本的trx_id属性值小于m_ids列表中最小的事务id，表明生成该版本的事务在生成ReadView前已经提交，所以该版本可以被当前事务访问。

  • 如果被访问版本的trx_id属性值大于m_ids列表中最大的事务id，表明生成该版本的事务在生成ReadView后才生成，所以该版本不可以被当前事务访问。

  • 如果被访问版本的trx_id属性值在m_ids列表中最大的事务id和最小事务id之间，那就需要判断一下trx_id属性值是不是在m_ids列表中，如果在，说明创建ReadView时生成该版本的事务还是活跃的，该版本不可以被访问；如果不在，说明创建ReadView时生成该版本的事务已经被提交，该版本可以被访问。

如果某个版本

【一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义】

开源完整内容戳这里

的数据对当前事务不可见的话，那就顺着版本链继续去找下一个版本的数据记录，依然按照我们上边所说的步骤判断数据是否可见，依此类推，一直到版本链中的最后一个版本数据，如果最后一个版本的数据我也不可见的话，那么也就意味着该条记录对该事务不可见，查询结果就不包含该记录。 在MySQL当中，READ COMMITTED（读已提交）和REPEATABLE READ（可重复读）隔离级别的的一个非常大的区别就是它们生成ReadView的时机不同，我们来具体举例看一下喽。 按照上面我们画的版本链，来具体分析一下，这个版本链是怎么一步步生成的，以及我们查询的时候，MySQL是怎么来通过版本链决定数据我们是否可读（可见）的。 –[1]–【R****EAD COMMITTED — 每次读取数据前都生成一个ReadView】 假设说现在系统里有一个id为100的事务在执行：

Transaction 100

BEGIN;

UPDATE t SET name = ‘小B’ WHERE id = 1;

UPDATE t SET name = ‘小C’ WHERE id = 1;

注意哦：我们这个事务，我并没有提交。没有commit指令哦

复制代码

Transaction 200

BEGIN;

更新了一些别的表的记录

…

贴心小课堂：事务执行过程中，只有在第一次真正修改记录时（比如使用INSERT、DELETE、UPDATE语句），才会被分配一个单独的事务id，这个事务id是递增的。

此刻，表t中id为1的记录得到的版本链表如下所示：

image.png

千万注意，我上面事务100，还没提交哦，我可没有执行commit指令。 假设现在有一个使用READ COMMITTED（读已提交）隔离级别的事务开始执行：

使用READ COMMITTED隔离级别的事务（读已提交）

BEGIN;

SELECT1：Transaction 100、200未提交

SELECT * FROM t WHERE id = 1; # 得到的列name的值为’小A’

这个SELECT1的执行流程如下：

  • 在执行SELECT语句时会首先生成一个ReadView，ReadView的m_ids数组列表的内容就是[100,200]。

  • 然后从版本链中挑选可见的记录，从图中可以看出，最新版本的列name的内容是’小C’，该版本的trx_id值为100，在m_ids列表内，所以不符合我们的可见性要求，根据roll_pointer跳到下一个版本。

  • 下一个版本的列name的内容是’小B’，该版本的trx_id值也为100，也在m_ids列表内，所以也不符合要求，继续跳到下一个版本。

  • 下一个版本的列name的内容是’小A’，该版本的trx_id值为80，小于m_ids列表中最小的事务id100，所以这个版本是符合要求的，最后返回给用户的版本就是这条列name为’小A’的记录。

之后，我们把事务id为100的这个事务提交一下，如下：

Transaction 100

BEGIN;

UPDATE t SET name = ‘小B’ WHERE id = 1;

UPDATE t SET name = ‘小C’ WHERE id = 1;

COMMIT; //提交了哦

然后再到事务id为200的事务中更新一下表t中id为1的记录：

Transaction 200

BEGIN;

更新了一些别的表的记录

…

UPDATE t SET name = ‘小D’ WHERE id = 1;

UPDATE t SET name = ‘小F’ WHERE id = 1;

此刻，表t中id为1的记录的版本链就长这样：

image.png

然后再到刚才使用READ COMMITTED隔离级别的事务中继续查找这个id为1的记录，如下：

使用READ COMMITTED隔离级别的事务

BEGIN;

SELECT1：Transaction 100、200均未提交的时候执行的查询

SELECT * FROM t WHERE id = 1; # 得到的列name的值为’小A’

SELECT2：Transaction 100提交，Transaction 200未提交的时候执行的查询

SELECT * FROM t WHERE id = 1; # 得到的列name的值为’小C’

这个SELECT2的执行过程如下：

  • 在执行SELECT语句时会先生成一个ReadView，ReadView的m_ids列表的内容就是[200]（事务id为100的那个事务已经提交了，所以生成快照时就没有它了）。

  • 然后从版本链中挑选可见的记录，从图中可以看出，最新版本的列name的内容是’小F’，该版本的trx_id值为200，在m_ids列表内，所以不符合可见性要求，根据roll_pointer跳到下一个版本。

  • 下一个版本的列name的内容是’小D’，该版本的trx_id值为200，也在m_ids列表内，所以也不符合要求，继续跳到下一个版本。

  • 下一个版本的列name的内容是’小C’，该版本的trx_id值为100，比m_ids列表中最小的事务id200还要小，所以这个版本是符合要求的，最后返回给用户的版本就是这条列name为’小C’的记录。

以此类推，如果之后事务id为200的记录也提交了，再此在使用READ COMMITTED隔离级别的事务中查询表t中id值为1的记录时，得到的结果就是’小F’了，具体流程我们就不分析了。总结一下就是：使用READ COMMITTED隔离级别的事务在每次查询开始时都会生成一个独立的ReadView。 说完了隔离级别为【读已提交】不知道你理解了没有？如果不理解，烦请联系我，我们一起进行探讨。 接下来我们就来看一下当事务隔离级别为【可重复读】的时候，MVCC是如何控制数据可见性的。 –[2]–****【REPEATABLE READ —在第一次读取数据时生成一个ReadView】 对于使用REPEATABLE READ隔离级别的事务来说，只会在第一次执行查询语句时生成一个ReadView，之后的查询就不会重复生成了。我们还是用例子看一下是什么效果。 比方说现在系统里有两个id分别为100、200的事务在执行：

Transaction 100

BEGIN;

UPDATE t SET name = ‘小B’ WHERE id = 1;

UPDATE t SET name = ‘小C’ WHERE id = 1;

Transaction 200

BEGIN;

更新了一些别的表的记录

…

此刻，表t中id为1的记录得到的版本链表如下所示：

image.png

假设现在有一个使用REPEATABLE READ隔离级别的事务开始执行：

使用REPEATABLE READ隔离级别的事务

BEGIN;

SELECT1：Transaction 100、200未提交

SELECT * FROM t WHERE id = 1; # 得到的列name的值为’小A’

这个SELECT1的执行过程如下：

  • 在执行SELECT语句时会先生成一个ReadView，ReadView的m_ids列表的内容就是[100, 200]。

  • 然后从版本链中挑选可见的记录，从图中可以看出，最新版本的列name的内容是’小C’，该版本的trx_id值为100，在m_ids列表内，所以不符合可见性要求，根据roll_pointer跳到下一个版本。

  • 下一个版本的列name的内容是’小B’，该版本的trx_id值也为100，也在m_ids列表内，所以也不符合要求，继续跳到下一个版本。

  • 下一个版本的列name的内容是’小A’，该版本的trx_id值为80，小于m_ids列表中最小的事务id100，所以这个版本是符合要求的，最后返回给用户的版本就是这条列name为’小A’的记录。

之后，我们把事务id为100的事务提交一下，就像这样：

Transaction 100

BEGIN;

UPDATE t SET name = ‘小B’ WHERE id = 1;

UPDATE t SET name = ‘小C’ WHERE id = 1;

COMMIT;

然后再到事务id为200的事务中更新一下表t中id为1的记录：

Transaction 200

BEGIN;

更新了一些别的表的记录

…

UPDATE t SET name = ‘小D’ WHERE id = 1;

UPDATE t SET name = ‘小F’ WHERE id = 1;

此刻，表t中id为1的记录的版本链就长这样：

image.png

然后再到刚才使用REPEATABLE READ隔离级别的事务中继续查找这个id为1的记录，如下：

Huawei开源分享
关注
专栏目录
在微服务架构下MySQL设计及优化
程序员光剑
07-30 1665
微服务”这个词汇已经在最近几年成为最热门的话题之一，其出现也对软件架构和开发模式产生了深远影响。现在越来越多的公司选择使用微服务架构构建应用，特别是在大型互联网公司中，更是不可避免的趋势。微服务架构将单体应用拆分成多个服务，每个服务运行在自己的进程中，彼此之间通过轻量级通信机制(RPC、消息队列等)进行交互。这样做带来的好处显而易见——独立部署，弹性伸缩，模块化开发和维护，更容易应对复杂的业务逻辑。但同时它也带来一些挑战。比如服务间通讯、服务发现、限流熔断、数据一致性、事务处理等。服务间的数据同步。
【springboot微服务】Lucence实现Mysql全文检索
congge
04-10 8175
Lucence实现Mysql全文检索
mysql深度分页优化研究
风雪夜归人的博客
08-12 371
mysql深度分页优化研究
MySQL 千万数据量深分页优化, 拒绝线上故障！
Long-Tai
12-25 2794
前言 优化项目代码过程中发现一个千万级数据深分页问题，缘由是这样的 库里有一张耗材 MCS_PROD 表，通过同步外部数据中台多维度数据，在系统内部组装为单一耗材产品，最终同步到 ES 搜索引擎 MySQL 同步 ES 流程如下： 通过定时任务的形式触发同步，比如间隔半天或一天的时间频率 同步的形式为增量同步，根据更新时间的机制，比如第一次同步查询 >= 1970-01-01 00:00:00.0 记录最大的更新时间进行存储，下次更新同步以此为条件 以分页的形式获取数据，当前页数量加一，循环..
项目收获总结--MySQL深度分页优化
最新发布
qq_40623672的博客
08-02 662
- MySQL 在无法利用索引的情况下跳过1000000条记录后，再获取10条记录。
MySQL深度分页优化
JavaMa的博客
05-16 6818
Mysql深度分页优化 1. 背景 mysql使用select * from table limit offset, rows分页在深度分页的情况下, 性能急剧下降。 例如：select * 的情况下直接⽤limit 600000，10 扫描的是约60万条数据，并且是需要回表 60W次，也就是说⼤部分性能都耗在随机访问上，到头来只⽤到10条数据(总共取600010条数据只留10条记录) 2. 优化 2.1 业务层面限制跨度比较大的跳页 百度和Google方案: [外链图片转存失败,源站可能有防盗链机制,
MySQL 深度分页优化
Songbl_的博客
08-15 585
分页使用limit ，前提是要排序好的数据，这时候，就推荐使用带索引的字段排序，因为索引是天然有序的，不需要像是无序的字段一样，全表扫描，如果太大的话，还filesort ，利用文件排序，排序完成之后，才能分页，很慢。但是，如果分页过深的话，比如limit100万，仍然无需要查询到100万数据，中间有大量的io操作（回表查询其它字段），这时候考虑用上子查询，先查到100万位置的往后10条数据（直接用id主键查，因为没有回表，直接索引查，所以很快），然后再关联10条数据，取得完整的数据。
MySQL 深分页优化
小楠的博客
09-20 412
而在第二条语句中，offset 设置为 6000000，则会在 InnoDB 的主键索引中获取第 0 ～ 6000000 + 10 条完整的行数据，返回给 server 层后根据 offset 的数值进行丢弃，只保留后面的 size 条数据，放到 server 层的结果集中，最后返回给客户端。针对第一条语句，server 层会调用 InnoDB 接口，在 InnoDB 的主键索引中获取到第 0 ～ 10 条完整的行数据，一次性返回给 server 层，并放到 server 层的结果集中，最后返回给客户端。
MySQL 千万数据量深分页优化
m0_63550462的博客
10-31 277
在说MVCC之前呢？我们先需要对那些不太了解MySQL的兄弟们，先普及普及MySQL一些基本知识，具体MVCC内容往后看哦。 我们通过案例一步一步查看MySQL的MVCC到底是什么东西。 ** 在MySQL当中，只有使用了InnoDB存储引擎的数据库表才支持事务。 有了事务就可以用来保证数据的完整以及一致性，保证成批的SQL语句要么全部执行，要么全部不执行。 事务用来管理insert、update、delete语句。 1、四个特性（ACID）： **原子性：**一个事务（transaction）中的
MySQL千万数据量深分页优化，重难点整理
m0_56835488的博客
06-10 341
一、前言 Redis 提供了5种数据类型：String（字符串）、Hash（哈希）、List（列表）、Set（集合）、Zset（有序集合），理解每种数据类型的特点对于redis的开发和运维非常重要。 备注： 按照分析顺序，本节应该说道有序集合对象了，但是考虑到有序集合对象的底层实现中使用到了跳跃表结构，避免在分析有序集合时造成突兀，所以本节先来看看 redis 中跳跃表结构的具体实现。 珍藏版（1）——Mybatis入门 1.什么是MyBatis 2.为什么我们要用Mybatis? 3.Mybatis
用vue与springcloud微服务架构开发的在线考试系统
04-24
项目简介：在线考试系统，采用vue与springcloud微服务架构开发，前后端完全分离，json格式数据交互，全部由本人独立开发完成。目前项目已部署在本人的学生版阿里云centos7服务器上。 ​主要功能有：对班级和科目的...
开发知识点-分布式微服务技术栈 SpringCloud
aming小老弟
10-19 2663
分布式架构的一种把服务进行 拆分springcloud 解决了 服务拆分过程中的 治理问题与单体应用 进行区分（单体架构 把业务所有功能集中开发，打成一个包部署）每个模块独立开发和部署（服务集群）服务之间互相调用出现分布式技术WebserviceESBHessionDubbo异步通信 消息队列（秒杀）敏捷开发思想高内聚低耦合微服务 + 持续集成。
从入门到精通！java架构师技术栈
m0_56662269的博客
05-13 559
一、前言 聊的是八股的文，干的是搬砖的活！ 面我的题开发都用不到，你为什么要问？可能这是大部分程序员求职时的经历，甚至也是大家讨厌和烦躁的点。明明给的是拧螺丝的钱、明明做的是写CRUD的事、明明担的是成工具的人！ 明明… 有很多，可明明公司不会招5年开发做3年经验的事、明明公司也更喜欢具有附加价值的研发。有些小公司不好说，但在一些互联网大厂中，我们都希望招聘到具有培养价值的，也更喜欢能快速打怪升级的，也更愿意让这样的人承担更大的职责。 但，你酸了！ 别人看源码你打游戏、别人学算法你刷某音、别人写博
MySQL深分页优化
Mamba Out
06-06 1175
MySQL中的深分页问题通常是指当我们通过LIMIT语句查询数据，尤其是在翻到较后面的页码时，性能会急剧下降。例如，查询第1000页的数据，每页10条，系统需要跳过前9990条数据，然后才能获取到所需的记录，这在大数据集上非常低效。传统的深分页实现方法通常是使用OFFSET和LIMIT这会导致数据库扫描大量不需要的行然后抛弃它们，才能获取到真正需要的数据。
MYSQL深度分页
weixin_44510100的博客
05-17 382
深度分页sql查询
MySQL 深度分页
We choose to go to the moon in this decade and do the other things, not because they are easy, but beacase they are hard.
01-18 3249
MySQL 深度分页
MySQL深度分页
Hello World
05-08 3045
深度分页问题的本质是在 MySQL 数据库中，通过 LIMIT 和 OFFSET 关键字进行分页时，MySQL 需要在每次查询时扫描整张表，直到找到当前页的数据。这种查询方式需要进行大量的磁盘 I/O 和内存操作，导致查询效率非常低下。当我们每次查询的记录数很小，但是查询次数很多时，就会产生大量的 I/O 操作，严重影响查询效率。例如有个sql假设假如 LIMIT 和 OFFSET 关键字同时进行使用的话，limit语句会先扫描offset+n行，然后再丢弃掉前offset行，返回后n行数据。
实战！聊聊如何解决MySQL深分页问题
黑帽子技术的博客
09-26 582
前言 ...
MySQL-深度分页如何优化
子悠のziyou
02-26 1169
延迟关联的优化思路，跟子查询的优化思路其实是一样的：都是把条件转移到主键索引树，然后减少回表。先查询出所需要的数据的主键id，因为在非聚集索引中每个叶子节点记录的数据为其id，这样就不需要回表查询，然后再去主键索引中查询。根据业务实际需求，看能否替换为上一页，下一页的功能，这样子就可以通过和上次数据进行比较，搭上树分支过滤的快车。深度分页造成的结果，offset越来越大，回表的记录越来越多，SQL查询性能急剧下降，会出现大量的慢SQL。直接通过主键索引查找，省略了二级索引查找过程，性能更高。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值