背景：
公司內部的一個系統實現的時候用了分表，方案是開源的ShardingSphere 分表算法使用了100取模，100張表嗯嗯數據量太大，對於歷史數據還使用了定時任務遷移。這些架構設計會在另一篇文章詳談。
故障：
某日，數據庫告警，cup報警，發現多條慢查詢日志（部分查詢高達8分鍾...），進而導致業務受到影響
以下是阿里雲洞察詳情
從日志中看到多條慢日志的offset超級大，導致很多無用查詢，這里還導致返回記錄特別多，
but，怎么導致這個結果的？？
原因：
沒有手動執行過這種sql，也沒有接口提供這種入口。
從查詢的時間點篩選請求日志發現請求是通過一個分頁觸發的，比如下面這個分頁，現在點擊最后一頁3332，（頁面是按照時間正序排列的，看最后一頁可以看最新的數據）
當篩選條件中添加指定多個應用時，我們會在多個表里查找...然后...分頁，記得之前看文檔說shardingsphere分頁的時候會分頁修正，見下圖
So，這時候選擇多個表，並選擇尾頁查詢，shardding就會把每張表里符合條件的數據査出來，合並排序拿到最終數據。這就算MySQL受得了，服務器也受不了啊
解決方案：
了解原因后解決方案也出來了，如果想看最后的頁，那就倒過來看開始的頁就可以了：添加排序按鈕，並讓前端只顯示前幾頁來隱藏入口，接口也禁止使用太大的頁數查詢
頁面實現效果：
至此，使用分庫分表插件shardingsphere分頁查詢尾頁最后幾頁導致的mysql數據庫服務器報警的問題解決了。