核心觀點：資料庫往往是「替罪羊」
分析多個客戶案例發現，分散式 Java 應用效能問題多源於中介層基礎建設，而非資料庫本身：
- 關鍵交易需串接 7 台服務器，部分已達 100% CPU 導致連線等待
- 監控功能被關閉以「節省資源」，事後無法追蹤跨服務呼叫鏈
- 服務未檢查 SQL 錯誤碼，資料庫未定義參考完整性 → 髒資料產生
- ORM (Hibernate/iBatis) 一次載入百萬筆記憶體 → OOM 或無錯誤停擺
四大專案啟動必問問題
- 交易量預估：「每日 500 萬筆，含 100 萬更新、200 萬插入、1500-2000 萬頁面瀏覽」——需有數據支撐
- 硬體規格：CPU 核心數/速度、記憶體配置、網路頻寬/連線數
- 監控設施：專案啟動即建立效能基線 (CPU 負載、網路流量)
- 服務拓撲圖：取得應用執行圖，掌握服務調用鏈，夜間除錯時可快速定位非資料庫瓶頸
Java 應用開發禁忌與對策
| 問題模式 | 後果 | 修正建議 |
|---|
| 一次 FETCH 全部結果集到記憶體/持久層 | 測試環境正常 (少量資料)，上線遇百萬筆 → OOM/靜默失敗 | 使用 FETCH FIRST xx ROWS 游標分頁處理 |
| 忽略 SQL 錯誤碼 | 資料庫錯誤被吞沒，資料完整性受損 | 強制檢查 SQLCODE/SQLSTATE，資料庫層定義 RI 約束 |
| 關閉監控 | 無歷史數據支援事後分析 | 啟用監控，建立跨服務追蹤機制 (統一時區時間戳) |
Web 尖峰負載規劃
尖峰往往是平均的 5-10 倍。容量規劃必須以尖峰為基準，並預留緩衝。
結語
「資料庫問題」會趕走用戶。完善基礎建設、監控與服務拓撲，才是穩定效能的關鍵。更多技巧請參考 IDUG 大會與 IDUG.org。
