【死磕Sharding-jdbc】---结果合并总结

分页性能分析

性能瓶颈

查询偏移量过大的分页会导致数据库获取数据性能低下,以MySQL为例:

SELECT * FROM t_order ORDER BY id LIMIT 1000000, 10

这句SQL会使得MySQL在无法利用索引的情况下跳过1000000条记录后,再获取10条记录,其性能可想而知。而在分库分表的情况下(假设分为2个库),为了保证数据的正确性,SQL会改写为:

SELECT * FROM t_order ORDER BY id LIMIT 0, 1000010

即将偏移量前的记录全部取出,并仅获取排序后的最后10条记录。这会在数据库本身就执行很慢的情况下,进一步加剧性能瓶颈。因为原SQL仅需要传输10条记录至客户端,而改写之后的SQL则会传输1000010*2的记录至客户端。

Sharding-JDBC的优化

Sharding-JDBC进行了2个方面的优化。

首先,Sharding-JDBC采用流式处理 + 归并排序的方式来避免内存的过量占用。Sharding-JDBC的SQL改写,不可避免的占用了额外的带宽,但并不会导致内存暴涨。 与直觉不同,大多数人认为Sharding-JDBC会将1000010*2记录全部加载至内存,进而占用大量内存而导致内存溢出。 但由于每个结果集的记录是有序的,因此Sharding-JDBC每次比较仅获取各个分片的当前结果集记录,驻留在内存中的记录仅为当前路由到的分片的结果集的当前游标指向而已。 对于本身即有序的待排序对象,归并排序的时间复杂度仅为O(n),性能损耗很小。

其次,Sharding-JDBC对仅落至单分片的查询进行进一步优化。落至单分片查询的请求并不需要改写SQL也可以保证记录的正确性,因此在此种情况下,Sharding-JDBC并未进行SQL改写,从而达到节省带宽的目的。

更好的分页解决方案

由于LIMIT并不能通过索引查询数据,因此如果可以保证ID的连续性,通过ID进行分页是比较好的解决方案:

SELECT * FROM t_order WHERE id > 100000 AND id <= 100010 ORDER BY id

或通过记录上次查询结果的最后一条记录的ID进行下一页的查询:

SELECT * FROM t_order WHERE id > 100000 LIMIT 10

摘自:sharding-jdbc使用指南☞分页及子查询

是否需要这种分页

无论是 SELECT *FROM t_order ORDER BY id LIMIT 0,100010或者 SELECT *FROM t_order WHERE id >100000LIMIT 10,性能都一般般,后者只是稍微好点而已,但是由于LIMIT的存在,mysql都需要排序;

是否能从产品角度或者用户习惯等方面解决或者避免这个问题?

  • 用户习惯结合产品需求解决方案:

比如我们以前有个每日TOP榜单需求,分析用户行为一般不会无限制往下滑,即使有这种用户,也是极少数,可以忽略。这样的话,可以通过SQL ***LIMIT 300只查询10页总计300个TOP应用,然后把这些数据以list结构保存到redis中。这样的话,用户查看每日TOP榜单只需通过 LRANGE key start stop从redis缓存中取数据即可,且限制查询的offset不允许超过300;

END

原文发布于微信公众号 - Java技术驿站(chenssy89)

原文发表时间:2018-05-28

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏aoho求索

MySQL探秘(五):InnoDB锁的类型和状态查询

 锁是数据库系统区分于文件系统的一个关键特性。数据库使用锁来支持对共享资源进行并发访问,提供数据的完整性和一致性。此外,数据库事务的隔离性也是通过锁实现的。In...

971
来自专栏数据和云

循序渐进:Oracle 12c新特性Sharding技术解读

引言 数据库构架设计中主要有 Shared Everthting、Shared Nothing 和 Shared Disk: Shared Everthting...

4517
来自专栏技术沉淀

Python: 操作MySQL数据库

1704
来自专栏Java面试通关手册

Mysql锁机制简单了解一下

Java面试通关手册(Java学习指南,欢迎Star,会一直完善下去,欢迎建议和指导):https://github.com/Snailclimb/Java_G...

16511
来自专栏后端技术探索

mysql 水平分表的几种方法

当一张的数据达到几百万时,你查询一次所花的时间会变多,如果有联合查询的话,我想有可能会死在那儿了。分表的目的就在于此,减小数据库的负担,缩短查询时间。

1K2
来自专栏友弟技术工作室

MySQL优化思路及框架

MySQL优化框架 1. SQL语句优化 2. 索引优化 3. 数据库结构优化 4. InnoDB表优化 5. MyISAM表优化 6. Memory表优化 7...

36910
来自专栏数据和云

【云和恩墨大讲堂】谈Oracle表新增字段的影响

作者简介 ? 刘晨,网名bisal,Oracle 10g/11g OCM,并国内首批Oracle YEP成员,博客:blog.itpub.net/bisal 很...

3037
来自专栏小怪聊职场

MySQL(七)|MySQL分库分表的那点事(小怪的Java群第一次话题讨论)

2614
来自专栏从ORACLE起航,领略精彩的IT技术。

Oracle数据库该如何着手优化一个SQL

3284
来自专栏杨建荣的学习笔记

数据清理的遗留问题处理(二)(r6笔记第91天)

之前尝试了历史数据的清理,在逻辑层面清除了数据,可以参见 http://blog.itpub.net/23718752/viewspace-1814000/ 但...

3025

扫码关注云+社区