MySQL 分表架構下的跨節點批量查詢設計模式（Java 實現）

背景與挑戰

當單表資料量達到百萬、千萬級，常見優化手段是水平分表：依主鍵範圍、時間欄位或業務條件，將資料拆分到多張同結構表，甚至分散到不同 MySQL 實例（Sharding）。但隨之而來的難題是：跨分片的批量查詢如何高效聚合？

本文提出應用層面的並行查詢管理器模式，並說明 JDBC 攔截與 MySQL 5.1 Partition 的差異。

一、 應用層實現：SelectThreadManager 並行查詢管理器

核心架構

• 為每個分片（Database 或 Server）建立獨立 Thread Pool。
• 提供三大介面：addTask()、stopTask()、getResult()。
• 查詢發起時，將任務分派到對應分片的 Thread Pool 並行執行。

執行時間模型

• 最快完成時間 = 最慢分片的查詢耗時（木桶效應）。
• 最慢完成時間 = 設定的全域超時時間。

繁忙分片的背壓處理流程

1. 某 ThreadPool N 極度繁忙（對應 DB N 負載高）。
2. 新查詢任務到達，addTask() 將新 Thread 排入 Pool N 隊列。
3. 外層應用已收到其他分片結果，進入等待狀態。
4. 等待超時，外層呼叫 stopTask() 設定所有相關 Thread 的停止旗標，並返回部分結果或報錯。
5. 稍後 Pool N 取到該任務，檢測到停止旗標，線程直接結束釋放資源。

此機制避免單一熱點分片拖垮整體查詢響應，實現「快速失敗」與資源隔離。

二、 JDBC 層透明攔截實現

為了不侵入業務代碼，可封裝一個 JDBC Driver Wrapper，攔截 PreparedStatement、Statement 的 executeQuery()，解析 SQL 中的分片鍵，自動路由到 SelectThreadManager 執行並聚合結果。對上層應用完全透明，僅需更換 JDBC URL 與 Driver 類名。

三、 MySQL 5.1 Partition 與手工分表的本質區別

結論：Partition 僅解決 IO 層面的單表過大問題，無法利用多核 CPU 並行計算。對於高併發、大數據量的 OLAP 或複雜 OLTP 場景，手工分表 + 應用層並行查詢管理器仍是更強的架構選擇。

四、 實作建議

• Thread Pool 大小根據分片數與機器核心數設定，避免過度建立線程導致上下文切換開銷。
• 引入查詢超時機制（如 3-5 秒），防止長尾查詢佔用資源。
• 結果聚合階段注意記憶體壓力，大結果集建議流式處理或分頁返回。
• 監控各分片查詢延遲、錯誤率、隊列積壓，配合熔斷器自動剔除異常分片。