資料庫分庫，原來 SQL 和儲存過程寫的報表咋辦？

分庫以後，儲存過程直接就被判死刑了，鐵定不能再用了；SQL 還要看情況（如多表 JOIN），總體來說方向有三個：

一、使用資料庫中介軟體

使用像 Mycat 之類的資料庫中介軟體，報表裡的簡單 SQL 基本都能延續使用（像 Mycat 支援 SQL92 標準），但對複雜 SQL（巢狀查詢和多表 JOIN）就比較麻煩，要考慮全域性表等設定。而報表業務裡複雜查詢會很多，有些還伴隨過程和邏輯判斷，這時用資料庫中介軟體就有點吃力了。

這裡列一下報表場景下使用資料庫中介軟體的缺點：
< 缺點 >

1. 複雜計算支援不足，且無儲存過程替代方案；
2. 多樣性資料來源支援不足，如報表資料來源還有檔案或 NoSQL 時；
3. 高耦合，移植性差，仍然存在資料庫中間表造成資料庫和報表高耦合的問題

參考資料：

二、使用 JAVA 硬編碼

為了彌補資料庫中介軟體的缺點，還可以在應用端使用 JAVA 硬編碼為報表準備資料。這樣原來的複雜 SQL 和儲存過程就可以透過編碼實現，而多樣性資料來源也不再是問題。但硬編碼的缺點也很明顯：

1. 太難了。用 JAVA 實現報表資料準備，完成各類集合運算對專業程式設計師都已經很困難（腦補一下寫個 group by 的程式碼量），更別說讓報表開發人員來做了；
2. 容易造成報表模組和應用的高耦合。報表的 JAVA 程式碼和應用程式碼一起部署，報表模組和應用其他模組緊耦合在一起，沒法單獨維護；
3. 沒法熱切換。報表修改以後，要重啟整個應用才能生效，而報表卻是經常要改…

三、使用支援分庫查詢的報表工具

有的報表工具直接支援分庫查詢，像 介紹的，主要藉助了工具本身提供的指令碼計算能力，這樣簡單 SQL 可以延用，對於複雜計算（複雜 SQL 和儲存過程）則透過分步的過程計算來實現，對人員要求也不高。
另外，對多樣性資料來源的支援也解決了異構源之間的關聯計算問題，同時解釋執行的指令碼支援熱切換。這樣，整個報表模組就可以單獨維護，報表修改也不會影響整個應用（對報表應用解耦感興趣可以看一下 ）。當然使用這種方式也有缺點：

1. 適應新的工具。引入新的報表工具勢必會帶來一定的學習成本。

分庫的確會讓報表開發和維護環境變得複雜，選用何種方式應對，要充分考慮自身業務和技術資源的實際情況。使用時可以“一二”組合，也可以“一三”組合，或者直接用“三”。