sharding-jdbc實現(xiàn)分頁查詢的示例代碼
詳解sharding-jdbc分頁查詢
前置步驟
之前的文章已經(jīng)介紹過sharding-jdbc底層會通過重寫數(shù)據(jù)源對應的prepareStament完成分表查詢邏輯，而分頁插件則是攔截SQL語句實現(xiàn)分頁查詢，所以使用sharding-jdbc進行分頁查詢只需引入用戶所需的分頁插件即可，以筆者為例，這里就直接使用pagehelper：
<!-- pagehelper 插件-->
<dependency>
<groupId>com.github.pagehelper</groupId>
<artifactId>pagehelper-spring-boot-starter</artifactId>
</dependency>
分頁查詢代碼示例
本文中筆者配置的分頁算法是通過id取模的方式，假設我們的對應的user數(shù)據(jù)id為1，按照我們的算法，它將被存至1%3=1即user_1表：
##使用哪一列用作計算分表策略，我們就使用id
spring.shardingsphere.sharding.tables.user.table-strategy.inline.sharding-column=id
##具體的分表路由策略，我們有3個user表，使用主鍵id取余3，余數(shù)0/1/2分表對應表user_0,user_2,user_2
spring.shardingsphere.sharding.tables.user.table-strategy.inline.algorithm-expression=user_$->{id % 3}
筆者在實驗表中插入大約100w的數(shù)據(jù)，進行一次分頁查詢,其中分頁算法為id%3
@Test
void selectByPage() {
//查詢第2頁的數(shù)據(jù)10條
PageHelper.startPage(2, 10, false);
//查詢結果按照id升序排列
UserExample userExample = new UserExample();
userExample.setOrderByClause("id asc");
//輸出查詢結果
List<User> userList = userMapper.selectByExample(userExample);
userList.forEach(System.out::println);
}
最終結果如下，可以看到查詢結果和單表情況下是一樣的，即從11~20：
User(id=11, name=user11, phone=) User(id=12, name=user12, phone=) User(id=13, name=user13, phone=) User(id=14, name=user14, phone=) User(id=15, name=user15, phone=) User(id=16, name=user16, phone=) User(id=17, name=user17, phone=) User(id=18, name=user18, phone=) User(id=19, name=user19, phone=) User(id=20, name=user20, phone=)
詳解sharding-jdbc對于分頁查詢的底層實現(xiàn)
按照正常的單表查詢邏輯，假設我們要查詢第2頁的數(shù)據(jù)10條，我們對應的SQL就是:
select * from user limit (page-1)*10,size =>select * from user limit 10,10
而sharding-jdbc分表分頁查詢則比較粗暴，它會將對應分頁及之前的數(shù)據(jù)全部查詢來，然后進行排序，跳過對應頁碼的數(shù)據(jù)后，再取出對應量級的數(shù)據(jù)返回。
以我們的分頁查詢?yōu)槔?，它會將每個分表的按照id進行升序排列之后取出各自的前20條數(shù)據(jù)，每張分表前20條數(shù)據(jù)之后，sharding-jdbc會根據(jù)我們的排序算法比對各張分表的第一條數(shù)據(jù)，很明顯user_1對應的結果最小，所以按照此規(guī)則輪詢分表的user_1、user_2、user_0以此將這3組結果存放至優(yōu)先隊列中。
基于這個隊列，sharding-jdbc會按照分頁查詢的邏輯跳過10個，所以它會不斷取出優(yōu)先隊列中的第一個元素，然后將這組分表結果再次存回隊列，以我們的查詢?yōu)槔褪?
- 從
user_1取出id為1的值，作為skip的第一個元素。 - 將
user_1查詢結果入隊，因為頭元素為4，和其他兩組比最大，所以存放至隊尾。 - 再次從優(yōu)先隊列中拿到
user_2的隊首元素2，作為skip的第2個元素，然后再次存入隊尾。 - 依次步驟完成跳過10個。
- 然后再按照這個規(guī)律篩選出10個，最終得到11~20。
源碼印證
基于上述的圖解，我們通過源碼解析方式來印證，首先mybatis會基于我們的SQL調用execute方法獲取查詢結果，然后再通過handleResultSets生成列表并返回。 我們都知道sharding-jdbc通過自實現(xiàn)數(shù)據(jù)源的同時也給出對應的PreparedStatement即ShardingPreparedStatement，所以execute方法本質的執(zhí)行者就是ShardingPreparedStatement，它會得到第2頁之前的所有數(shù)據(jù)，然后通過handleResultSets進行skip和limit得到最終結果：
@Override
public <E> List<E> query(Statement statement, ResultHandler resultHandler) throws SQLException {
PreparedStatement ps = (PreparedStatement) statement;
//調用sharding-jdbc的ShardingPreparedStatement的execute獲取各個分表前2頁的所有數(shù)據(jù)
ps.execute();
//通過skip結合limit得到所有結果
return resultSetHandler.handleResultSets(ps);
}
步入execute方法可以看到其內部本質是調用preparedStatementExecutor進行查詢處理的：
@Override
public boolean execute() throws SQLException {
try {
clearPrevious();
//獲取查詢SQL
shard();
initPreparedStatementExecutor();
//執(zhí)行SQL結果并返回
return preparedStatementExecutor.execute();
} finally {
clearBatch();
}
}
而該執(zhí)行方法最終會走到ShardingExecuteEngine的parallelExecute方法，通過異步查詢3張分表的結果，再通過外部傳入的回調執(zhí)行器處理這3個異步任務的查詢結果：
private <I, O> List<O> parallelExecute(final Collection<ShardingExecuteGroup<I>> inputGroups, final ShardingGroupExecuteCallback<I, O> firstCallback,
final ShardingGroupExecuteCallback<I, O> callback) throws SQLException {
Iterator<ShardingExecuteGroup<I>> inputGroupsIterator = inputGroups.iterator();
ShardingExecuteGroup<I> firstInputs = inputGroupsIterator.next();
//提交3個異步任務
Collection<ListenableFuture<Collection<O>>> restResultFutures = asyncGroupExecute(Lists.newArrayList(inputGroupsIterator), callback);
//通過回調執(zhí)行器callback阻塞獲取3個異步結果
return getGroupResults(syncGroupExecute(firstInputs, null == firstCallback ? callback : firstCallback), restResultFutures);
}
得到3張分表的數(shù)據(jù)之后，其內部邏輯最終會走到ShardingPreparedStatement的getResultSet方法，其內部會創(chuàng)建一個合并引擎DQLMergeEngine進行并調用getCurrentResultSet進行數(shù)據(jù)截?。?/p>
@Override
public ResultSet getResultSet() throws SQLException {
//......
if (routeResult.getSqlStatement() instanceof SelectStatement || routeResult.getSqlStatement() instanceof DALStatement) {
//反射創(chuàng)建分表合并引擎
MergeEngine mergeEngine = MergeEngineFactory.newInstance(connection.getShardingContext().getDatabaseType(),
connection.getShardingContext().getShardingRule(), routeResult, connection.getShardingContext().getMetaData().getTable(), queryResults);
//截取最終結果
currentResultSet = getCurrentResultSet(resultSets, mergeEngine);
}
return currentResultSet;
}
而該引擎就是DQLMergeEngine，進行合并操作時,會調用LimitDecoratorMergedResult跳過前10個元素：
private MergedResult decorate(final MergedResult mergedResult) throws SQLException {
Limit limit = routeResult.getLimit();
//......
//通過LimitDecoratorMergedResult跳過3張分表組合結果的前10個元素
if (DatabaseType.MySQL == databaseType || DatabaseType.PostgreSQL == databaseType || DatabaseType.H2 == databaseType) {
return new LimitDecoratorMergedResult(mergedResult, routeResult.getLimit());
}
//......
return mergedResult;
}
跳過的邏輯就比較簡單了，LimitDecoratorMergedResult會調用合并引擎調用OrderByStreamMergedResult的next方法跳過前10個元素：
//LimitDecoratorMergedResult的skipOffset跳過10個元素
private boolean skipOffset() throws SQLException {
for (int i = 0; i < limit.getOffsetValue(); i++) {
//調用OrderByStreamMergedResult跳過組合結果的前10個元素
if (!getMergedResult().next()) {
return true;
}
}
rowNumber = 0;
return false;
}
可以看到OrderByStreamMergedResult的邏輯就是我們上文所說的取出隊列中的第一組查詢結果的第一個元素，然后再將其存入隊(因為取出第一個元素后，隊首元素最大，這組結果會存至隊尾)，不斷循環(huán)跳夠10個:
@Override
public boolean next() throws SQLException {
//......
//取出隊列中第一組分表查詢結果的第一個元素
OrderByValue firstOrderByValue = orderByValuesQueue.poll();
//如果這組分表結果還有元素則將這組分表結果入隊，因為隊首元素最大，所以會存放至隊尾
if (firstOrderByValue.next()) {
orderByValuesQueue.offer(firstOrderByValue);
}
//......
return true;
}
經(jīng)過上述步驟跳過10個元素后，就要截取第二頁的10個數(shù)據(jù)了，代碼再次回到PreparedStatementHandler的handleResultSets方法，該方法會調用到DefaultResultSetHandler的handleRowValuesForSimpleResultMap方法，該方法會循環(huán)10個，通過resultSet.next()移到下一條數(shù)據(jù)的游標，然后生成對象存儲到resultHandler中，最終通過這個resultHandler就可以看到我們分頁查詢的List：
private void handleRowValuesForSimpleResultMap(ResultSetWrapper rsw, ResultMap resultMap, ResultHandler<?> resultHandler, RowBounds rowBounds, ResultMapping parentMapping)
throws SQLException {
DefaultResultContext<Object> resultContext = new DefaultResultContext<>();
ResultSet resultSet = rsw.getResultSet();
skipRows(resultSet, rowBounds);
//通過resultSet.next()方法調用
while (shouldProcessMoreRows(resultContext, rowBounds) && !resultSet.isClosed() && resultSet.next()) {
ResultMap discriminatedResultMap = resolveDiscriminatedResultMap(resultSet, resultMap, null);
Object rowValue = getRowValue(rsw, discriminatedResultMap, null);
storeObject(resultHandler, resultContext, rowValue, parentMapping, resultSet);
}
}
而next方法本質還是調用LimitDecoratorMergedResult的next方法，以rowNumber 來計數(shù)，調用mergedResult的next方法將游標移動到要返回的數(shù)據(jù)，
@Override
public boolean next() throws SQLException {
//......
//同樣基于優(yōu)先隊列取夠10個
return ++rowNumber <= limit.getRowCountValue() && getMergedResult().next();
}
而OrderByStreamMergedResult的next邏輯和之前差不多，就是通過輪詢優(yōu)先隊列中的每一組分表對象的隊首元素，將其存到currentQueryResult中，后續(xù)進行對象創(chuàng)建時就會從currentQueryResult中拿到這個結果生成User對象存入List中返回:
@Override
public boolean next() throws SQLException {
//......
//從優(yōu)先隊列orderByValuesQueue拿到隊首的一組分表查詢結果
OrderByValue firstOrderByValue = orderByValuesQueue.poll();
//移動當前隊列游標
if (firstOrderByValue.next()) {
orderByValuesQueue.offer(firstOrderByValue);
}
if (orderByValuesQueue.isEmpty()) {
return false;
}
//將當前優(yōu)先隊列中的隊首元素的queryResult作為本次的查詢結果，作為后續(xù)創(chuàng)建User對象的數(shù)據(jù)
setCurrentQueryResult(orderByValuesQueue.peek().getQueryResult());
return true;
}
存在的問題
自此我們了解了sharding-jdbc分頁查詢的內部工作機制，這里我們順便說一下這種算法的缺點，查閱官網(wǎng)說法是sharding-jdbc分頁查詢不會占用內存，說明查詢結果僅僅記錄的是游標：
首先，采用流式處理 + 歸并排序的方式來避免內存的過量占用。由于SQL改寫不可避免的占用了額外的帶寬，但并不會導致內存暴漲。 與直覺不同，大多數(shù)人認為ShardingSphere會將1,000,010 * 2記錄全部加載至內存，進而占用大量內存而導致內存溢出。 但由于每個結果集的記錄是有序的，因此ShardingSphere每次比較僅獲取各個分片的當前結果集記錄，駐留在內存中的記錄僅為當前路由到的分片的結果集的當前游標指向而已。 對于本身即有序的待排序對象，歸并排序的時間復雜度僅為O(n)，性能損耗很小。
但是筆者在使用過程中，打印內存快照時發(fā)現(xiàn)，進行500w數(shù)據(jù)的深分頁查詢發(fā)現(xiàn)，它的做法和我們上文源碼所說的一致，就是將當前頁以及之前的結果全部加載到內存中，所以筆者認為使用sharding-jdbc時還是需要注意一下對內存的監(jiān)控:
小結
以上就是sharding-jdbc實現(xiàn)分頁查詢的示例代碼的詳細內容，更多關于sharding-jdbc分頁查詢的資料請關注腳本之家其它相關文章！
相關文章
這篇文章主要介紹了通過實例了解cookie機制特性及使用方法,文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值,需要的朋友可以參考下2020-09-09
這篇文章主要介紹了Java 模擬cookie登陸簡單操作,結合實例形式分析了Java 模擬cookie登陸的相關原理與基本實現(xiàn)技巧,需要的朋友可以參考下2020-03-03
實例講解Java中random.nextInt()與Math.random()的基礎用法
今天小編就為大家分享一篇關于實例講解Java中random.nextInt()與Math.random()的基礎用法，小編覺得內容挺不錯的，現(xiàn)在分享給大家，具有很好的參考價值，需要的朋友一起跟隨小編來看看吧2019-02-02
這篇文章主要介紹了spring ioc的簡單實例及bean的作用域屬性解析，具有一定借鑒價值,需要的朋友可以參考下2017-12-12
這篇文章主要介紹了深入剖析Java編程中的序列化,文中談到了序列化時對象的繼承等各種問題,案例詳盡,強烈推薦!需要的朋友可以參考下2015-07-07
這篇文章主要介紹了關于SpringBoot中事務失效的幾種情況,Spring AOP默認使用動態(tài)代理，會給被代理的類生成一個代理類，事務相關的操作都通過代理來完成，使用內部方法調用時，使用的是實例調用，沒有通過代理類調用方法，因此事務不會檢測到失敗,需要的朋友可以參考下2023-08-08
這篇文章主要介紹了用Java生成二維碼并附帶文字信息,文中有非常詳細的代碼示例,對正在學習java的小伙伴們有非常好的幫助,需要的朋友可以參考下2021-04-04
這篇文章主要為大家介紹了Java集合之Disruptor操作示例介紹,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪2023-08-08
這篇文章主要為大家介紹了Lucene單值編碼壓縮算法源碼解析，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進步，早日升職加薪2022-11-11
詳解Spring整合mybatis--Spring中的事務管理(xml形式)
這篇文章主要介紹了Spring整合mybatis--Spring中的事務管理(xml形式),本文通過實例代碼給大家介紹的非常詳細，對大家的學習或工作具有一定的參考借鑒價值，需要的朋友可以參考下2023-11-11