分庫以後，存儲過程直接就被判死刑了，鐵定不能再用了；SQL 還要看情況（如多表 JOIN），總體來說方向有三個：
一、使用數據庫中間件
使用像 Mycat 之類的數據庫中間件，報表裏的簡單 SQL 基本都能延續使用（像 Mycat 支持 SQL92 標準），但對複雜 SQL（嵌套查詢和多表 JOIN）就比較麻煩，要考慮全局表等設置。而報表業務裏複雜查詢會很多，有些還伴隨過程和邏輯判斷，這時用數據庫中間件就有點喫力了。
這裏列一下報表場景下使用數據庫中間件的缺點：
< 缺點 >
1. 複雜計算支持不足，且無存儲過程替代方案；
2. 多樣性數據源支持不足，如報表數據來源還有文件或 NoSQL 時；
3. 高耦合，移植性差，仍然存在數據庫中間表造成數據庫和報表高耦合的問題
參考資料：Mycat 官網
二、使用 JAVA 硬編碼
爲了彌補數據庫中間件的缺點，還可以在應用端使用 JAVA 硬編碼爲報表準備數據。這樣原來的複雜 SQL 和存儲過程就可以通過編碼實現，而多樣性數據源也不再是問題。但硬編碼的缺點也很明顯：
1. 太難了。用 JAVA 實現報表數據準備，完成各類集合運算對專業程序員都已經很困難（腦補一下寫個 group by 的代碼量），更別說讓報表開發人員來做了；
2. 容易造成報表模塊和應用的高耦合。報表的 JAVA 代碼和應用代碼一起部署，報表模塊和應用其他模塊緊耦合在一起，沒法單獨維護；
3. 沒法熱切換。報表修改以後，要重啓整個應用才能生效，而報表卻是經常要改…
三、使用支持分庫查詢的報表工具
有的報表工具直接支持分庫查詢，像 分庫後的報表怎麼做 介紹的，主要藉助了工具本身提供的腳本計算能力，這樣簡單 SQL 可以延用，對於複雜計算（複雜 SQL 和存儲過程）則通過分步的過程計算來實現，對人員要求也不高。
另外，對多樣性數據源的支持也解決了異構源之間的關聯計算問題，同時解釋執行的腳本支持熱切換。這樣，整個報表模塊就可以單獨維護，報表修改也不會影響整個應用（對報表應用解耦感興趣可以看一下 如何降低報表應用的耦合度 ）。當然使用這種方式也有缺點：
1. 適應新的工具。引入新的報表工具勢必會帶來一定的學習成本。
分庫的確會讓報表開發和維護環境變得複雜，選用何種方式應對，要充分考慮自身業務和技術資源的實際情況。使用時可以“一二”組合，也可以“一三”組合，或者直接用“三”。