java一次查询900w数据_一次SQL查询优化原理分析(900W+数据,从17s到300ms)
有一张财务流水表,未分库分表,目前的数据量为9555695,分页查询使用到了limit,优化之前的查询耗时16 s 938 ms (execution: 16 s 831 ms, fetching: 107 ms),按照下文的方式调整SQL后,耗时347 ms (execution: 163 ms, fetching: 184 ms);
操作:查询条件放到子查询中,子查询只查主键ID,然后使用子查询中确定的主键关联查询其他的属性字段;
原理:
1、减少回表操作;
2、可参考《阿里巴巴Java开发手册(泰山版)》第五章-MySQL数据库、(二)索引规约、第7条:
【推荐】利用延迟关联或者子查询优化超多分页场景。
说明: MySQL并不是挑过offeset行,而是取offset+N行,然后返回放弃前offset行,返回N行,那当offset特别大的时候,效率就非常的底下,要么控制返回的总页数,要么对超过特定阈值的页数进行SQL改写。
正例: 先快速定位需要获取的id段,然后再关联:
SELECT a.* FROM 表1 a,(select id from 表1 where 条件 LIMIT 100000,20) b where a.id = b.id;
-- 优化前SQL SELECT 各种字段 FROM `table_name` WHERE 各种条件 LIMIT 0,10;
-- 优化后SQL SELECT 各种字段 FROM `table_name` main_tale RIGHT JOIN ( SELECT 子查询只查主键 FROM `table_name` WHERE 各种条件 LIMIT 0,10; ) temp_table ON temp_table.主键 = main_table.主键
一,前言
首先说明一下MySQL的版本:
mysql> select version(); +-----------+ | version() | +-----------+ | 5.7.17 | +-----------+ 1 row in set (0.00 sec)
表结构:
mysql> desc test; +--------+---------------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +--------+---------------------+------+-----+---------+----------------+ | id | bigint(20) unsigned | NO | PRI | NULL | auto_increment | | val | int(10) unsigned | NO | MUL | 0 | | | source | int(10) unsigned | NO | | 0 | | +--------+---------------------+------+-----+---------+----------------+ 3 rows in set (0.00 sec)
id为自增主键,val为非唯一索引。
灌入大量数据,共500万:
mysql> select count(*) from test; +----------+ | count(*) | +----------+ | 5242882 | +----------+ 1 row in set (4.25 sec)
我们知道,当limit offset rows中的offset很大时,会出现效率问题:
mysql> select * from test where val=4 limit 300000,5; +---------+-----+--------+ | id | val | source | +---------+-----+--------+ | 3327622 | 4 | 4 | | 3327632 | 4 | 4 | | 3327642 | 4 | 4 | | 3327652 | 4 | 4 | | 3327662 | 4 | 4 | +---------+-----+--------+ 5 rows in set (15.98 sec)
为了达到相同的目的,我们一般会改写成如下语句:
mysql> select * from test a inner join (select id from test where val=4 limit 300000,5) b on a.id=b.id; +---------+-----+--------+---------+ | id | val | source | id | +---------+-----+--------+---------+ | 3327622 | 4 | 4 | 3327622 | | 3327632 | 4 | 4 | 3327632 | | 3327642 | 4 | 4 | 3327642 | | 3327652 | 4 | 4 | 3327652 | | 3327662 | 4 | 4 | 3327662 | +---------+-----+--------+---------+ 5 rows in set (0.38 sec)
时间相差很明显。
为什么会出现上面的结果?我们看一下select * from test where val=4 limit 300000,5;的查询过程:
查询到索引叶子节点数据。
根据叶子节点上的主键值去聚簇索引上查询需要的全部字段值。
类似于下面这张图:
像上面这样,需要查询300005次索引节点,查询300005次聚簇索引的数据,最后再将结果过滤掉前300000条,取出最后5条。MySQL耗费了大量随机I/O在查询聚簇索引的数据上,而有300000次随机I/O查询到的数据是不会出现在结果集当中的。
肯定会有人问:既然一开始是利用索引的,为什么不先沿着索引叶子节点查询到最后需要的5个节点,然后再去聚簇索引中查询实际数据。这样只需要5次随机I/O,类似于下面图片的过程:
像上面这样,需要查询300005次索引节点,查询300005次聚簇索引的数据,最后再将结果过滤掉前300000条,取出最后5条。MySQL耗费了大量随机I/O在查询聚簇索引的数据上,而有300000次随机I/O查询到的数据是不会出现在结果集当中的。
肯定会有人问:既然一开始是利用索引的,为什么不先沿着索引叶子节点查询到最后需要的5个节点,然后再去聚簇索引中查询实际数据。这样只需要5次随机I/O,类似于下面图片的过程:
其实我也想问这个问题。
证实
下面我们实际操作一下来证实上述的推论:
为了证实select * from test where val=4 limit 300000,5是扫描300005个索引节点和300005个聚簇索引上的数据节点,我们需要知道MySQL有没有办法统计在一个sql中通过索引节点查询数据节点的次数。我先试了Handler_read_*系列,很遗憾没有一个变量能满足条件。
我只能通过间接的方式来证实:
InnoDB中有buffer pool。里面存有最近访问过的数据页,包括数据页和索引页。所以我们需要运行两个sql,来比较buffer pool中的数据页的数量。预测结果是运行select * from test a inner join (select id from test where val=4 limit 300000,5); 之后,buffer pool中的数据页的数量远远少于select * from test where val=4 limit 300000,5;对应的数量,因为前一个sql只访问5次数据页,而后一个sql访问300005次数据页。
select * from test where val=4 limit 300000,5
mysql> select index_name,count(*) from information_schema.INNODB_BUFFER_PAGE where INDEX_NAME in('val','primary') and TABLE_NAME like '%test%' group by index_name;Empty set (0.04 sec)
可以看出,目前buffer pool中没有关于test表的数据页。
mysql> select * from test where val=4 limit 300000,5; +---------+-----+--------+ | id | val | source | +---------+-----+--------+| 3327622 | 4 | 4 | | 3327632 | 4 | 4 | | 3327642 | 4 | 4 | | 3327652 | 4 | 4 | | 3327662 | 4 | 4 | +---------+-----+--------+ 5 rows in set (26.19 sec) mysql> select index_name,count(*) from information_schema.INNODB_BUFFER_PAGE where INDEX_NAME in('val','primary') and TABLE_NAME like '%test%' group by index_name; +------------+----------+ | index_name | count(*) | +------------+----------+ | PRIMARY | 4098 | | val | 208 | +------------+----------+2 rows in set (0.04 sec)
可以看出,此时buffer pool中关于test表有4098个数据页,208个索引页。
select * from test a inner join (select id from test where val=4 limit 300000,5) ;为了防止上次试验的影响,我们需要清空buffer pool,重启mysql。
mysqladmin shutdown /usr/local/bin/mysqld_safe &
mysql> select index_name,count(*) from information_schema.INNODB_BUFFER_PAGE where INDEX_NAME in('val','primary') and TABLE_NAME like '%test%' group by index_name; Empty set (0.03 sec)
运行sql:
mysql> select * from test a inner join (select id from test where val=4 limit 300000,5) b on a.id=b.id; +---------+-----+--------+---------+ | id | val | source | id | +---------+-----+--------+---------+ | 3327622 | 4 | 4 | 3327622 | | 3327632 | 4 | 4 | 3327632 | | 3327642 | 4 | 4 | 3327642 | | 3327652 | 4 | 4 | 3327652 | | 3327662 | 4 | 4 | 3327662 | +---------+-----+--------+---------+ 5 rows in set (0.09 sec) mysql> select index_name,count(*) from information_schema.INNODB_BUFFER_PAGE where INDEX_NAME in('val','primary') and TABLE_NAME like '%test%' group by index_name; +------------+----------+ | index_name | count(*) | +------------+----------+ | PRIMARY | 5 | | val | 390 | +------------+----------+ 2 rows in set (0.03 sec)
我们可以看明显的看出两者的差别:第一个sql加载了4098个数据页到buffer pool,而第二个sql只加载了5个数据页到buffer pool。符合我们的预测。也证实了为什么第一个sql会慢:读取大量的无用数据行(300000),最后却抛弃掉。
而且这会造成一个问题:加载了很多热点不是很高的数据页到buffer pool,会造成buffer pool的污染,占用buffer pool的空间。 遇到的问题
为了在每次重启时确保清空buffer pool,我们需要关闭innodb_buffer_pool_dump_at_shutdown和innodb_buffer_pool_load_at_startup,这两个选项能够控制数据库关闭时dump出buffer pool中的数据和在数据库开启时载入在磁盘上备份buffer pool的数据。
参考资料:
java一次查询900w数据_一次SQL查询优化原理分析(900W+数据,从17s到300ms)相关推荐
- 大量数据table_一次 SQL 查询优化原理分析(900W+ 数据,从 17s 到 300ms)
有一张财务流水表,未分库分表,目前的数据量为9555695,分页查询使用到了limit,优化之前的查询耗时16 s 938 ms (execution: 16 s 831 ms, fetching: ...
- plsql 自动查询最后页_一次SQL查询优化思考过程(900W+数据,从17s到300ms)
点击上方"java进阶架构师",选择右上角"置顶公众号" 20大进阶架构专题每日送达 作者:Muscleape https://www.jianshu.com/ ...
- 一次 SQL 查询优化原理分析(900W+ 数据,从 17s 到 300ms)
点击上方"方志朋",选择"设为星标" 回复"666"获取新整理的面试文章 来源:Muscleape jianshu.com/p/0768eb ...
- 一次SQL查询优化原理分析(900W+数据,从17s到300ms)
点击上方"方志朋",选择"设为星标" 回复"666"获取新整理的面试资料 作者 | Muscleape 来源 | https://www.j ...
- 搞懂 SQL 查询优化原理分析,秒速处理大数据量查询
点击上方"朱小厮的博客",选择"设为星标" 后台回复"书",获取 有一张财务流水表,未分库分表,目前的数据量为9555695,分页查询使用到 ...
- Java 数据交换格式反射机制SpringIOC原理分析
数据交换格式&反射机制&SpringIOC原理分析 什么是数据交换格式? 数据交换格式使用场景 JSON简单使用 什么是JSON? JSON格式的分类 常用JSON解析框架 使用fas ...
- java sql 写入万条数据_如何快速向数据库插1000万数据?4种方法对比,它简单却速度最快
目录 场景介绍 项目配置 Mybatis为什么慢? JdbcTemplate让我眼前一亮 原生JDBC就是快啊! 存储过程怎么样? 越简单越快 前言 一直有一种说法:批量插入大量数据到MySQL数据库 ...
- sql数据库查询聚合函数_如何使用SQL Server数据质量服务确保正确的数据聚合
sql数据库查询聚合函数 介绍 (Introduction) An interesting opportunity arose at a client site during early Octobe ...
- java后台对查询到的商品列表按店铺分组并返回json数据
List<ShoppingCart> cartList = shoppingService.getCartList(userId);//这是从数据库获取的购物车商品列表 Map<In ...
最新文章
- 孙正义:互联网流量将转化为智能AI流量,我的时代终于来了
- 【科普】:10分钟看明白XML和JSON
- 整合spring cloud云架构 - Gateway的基本入门
- zcmu-1931(dfs方格切割)
- mysql workbench第二栏图标中英文意思
- 实验一 Linux开发环境的配置 20145213祁玮 20145222黄亚奇
- linux后台运行和关闭、查看后台任务(转)
- 英特尔2021至强cpu性能排行天梯图
- 条件表达式的学习和使用 实例之闰年的判断
- HTML简单语法总结
- java误删的信息怎么恢复_记一次线上表数据误删恢复过程
- Redis存储数据类型,及存取值方法
- 爬取京东图书商品信息
- 腾讯课堂 H5 直播间点赞动效实现
- RGB排列和Pentile排列有什么区别
- 解决centos8 中安装mysql5.7.26时 libtinfo.so.5()(64bit)被依赖的问题
- Python 抓取新浪财经股票数据
- 联想集团2017财年营收430.35亿美元 净利润5.35亿美元
- LaTex论文排版 | (6) LaTex中的特殊符号
- 给Krpano小白们的最最最入门级教程(二)