mysql分頁查詢報錯:
前提:
1.每頁1000條數據
2.查到57頁的時候,就報錯了
以下是錯誤信息:

org.springframework.jdbc.UncategorizedSQLException: ### Error querying database. Cause: java.sql.SQLException: ...省略中間... received message larger than max (18441058 vs. 16777216) ### The error may exist in sqlmap/RxOrder.xml ### The error may involve defaultParameterMap ### The error occurred while setting parameters ### SQL: SELECT ...省略中間查詢... LIMIT ?,? at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:83) at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:80) at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:80) at org.mybatis.spring.MyBatisExceptionTranslator.translateExceptionIfPossible(MyBatisExceptionTranslator.java:71) ...省略后面

關于這個錯誤,網上幾乎沒有太多可用記錄,最初就猜想是分頁太深,導致內存滿了,畢竟是內存排序,最后找公司同事確認了,就是這個原因

解決方式就是優化sql,避開深度分頁

原sql: select * from table01 where id > 1000000000000 and id < 9000000000000 limit 57000,1000 sql的目的是分頁查出所有的數據,但因為分頁太深,導致數據庫內存爆滿,查詢就停止了優化方案1(單步改分步查詢): select id from table01 where id > 1000000000000 and id < 9000000000000 limit 56999,1 第一步,先查出第56999條的id select * from table01 where id > #{id} and id < 9000000000000 limit 57000,1000 第二步,直接從這個id開始向后拿1000條優化方案2(子查詢): select id from table01 where id > (select id from table01 where id > 1000000000000 and id < 9000000000000 limit 56999,1) and id < 9000000000000 limit 1000 原理和優化方案1一樣,只不過放在一個sql中了,但是數據量大的數據庫一般都分庫分表,至少也是分片,所以對子查詢的支持不是很好,因業務系統而異優化方案3(分步查詢唯一字段,再組裝): select id from table01 where id > 1000000000000 and id < 9000000000000 limit 57000,1000 先查出id的集合list,再遍歷這個集合,分別查出每個id對應的數據,再組裝起來 這樣的好處是將數據庫的內存壓力變相的轉移到服務器,一般服務器還是可以抗住的 但這樣的缺點也明顯,就是多了層查詢,會慢些優化方案4(縮小粒度): 業務原因,原來分頁是以天為最小粒度,每天是個線程,每個線程再查所有 優化的話可以考慮以小時為一個最小粒度,每個小時是一個線程,那么每個小時的數據量就沒那么大了,分頁也就不會太深了

總結:一切優化的根本目的都是為了避開一次性的大數據量的分頁

總結

以上是生活随笔為你收集整理的mysql分页查询报错,及解决的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。