軟硬體環境

OS：win7

Cpu：8 核

集算報表：1120 安裝版

Jvm：1G

資料庫：oracle11g

客戶無法解決的問題：

有一個交叉彙總報表，其實格式很簡單，行列各一個統計維度。但後臺業務表的資料有 175 萬條，且還要與其他表（大概在 7w 條左右）做 join，如果由 sql 來處理，可以想象到會慢到什麼程度，關鍵受各種條件影響，能否查出資料都是問題。

注：ACCORECEIVE 表 175w 條資料

目前，測試 birt 需 5 分鐘，藉助各種中間表與檢視。報表友商無法出表。

要求：能做出該報表在 web 展現，且重要的是速度要快，另外，資料（目前大概是 5 年資料）是實時增加的。

客戶報表格式及目前所用 sql：

報表格式：

Sql：

select LOCATIONS.loupan loupan,
       LOCATIONS.LPORDERNUM,
       nvl(ACCORECEIVE.RECEIVABLEAMOUNT, 0) yingshou,
       chargeproct.Description CHARPNAME,
       chargeproct.ordernum chordernum
  from ACCORECEIVE,V\_LOCATION\_LP\_LG\_DY LOCATIONS,chargeproct
   where ACCORECEIVE.Org\_Id = LOCATIONS.Org\_Id
   and ACCORECEIVE.Sub\_Org\_Id = LOCATIONS.Sub\_Org\_Id
   and ACCORECEIVE.Fk_Locationid = LOCATIONS.Locationid
   and ACCORECEIVE.Fk_Chargeproctid = chargeproct.chargeproctid(+)
   and ACCORECEIVE.Wf_Status not in('作廢')

問題分析及解決方案

常規模式下，大資料要出交叉報表幾乎很難，這裡受 sql 效率慢、jvm 等的影響，一次如果把所有資料全部取出則必然極大可能記憶體溢位。另外，大資料表再有 join，即便能取，那取數速度上肯定也無法保證（sql join 的效率低），上面 sql 中能體現出所有問題。

解決方案：

1、為避免一次性取數記憶體溢位，可採用集算器遊標 cursor 取數；  –cursor

2、去除不需要欄位及 join 欄位。分析後發現，客戶實際不需要 org_id、sub_org_id 的關聯；

3、取數後可根據客戶所出報表對應做資料處理，這裡可 groups 處理一次分組彙總；–替代報表表示式 group

4、為擺脫 sql join 效率低問題，可將 join 放在集算器內處理，這裡 ACCORECEIVE 與 V_LOCATION_LP_LG_DY 表（query 即可，資料不大）分開取數；  –switch 連線

注：集算器中測試了兩表 sql 中 join，時間大概需 5 分鐘。

5、結合客戶報表格式及所用的資料庫表，可將上面 sql 中 chargeproct 表放到報表 sql 取數，因其僅體現顯示值作用，且僅幾十條資料。

集算指令碼：

注：程式碼有每一步的作用說明

結論
–

潤乾能出表且速度最快，客戶聯絡人是非常滿意的。對比：

1、友商：無法出表，包含不做 join 僅單查業務表資料。

2、Birt：客戶說 4、5 分鐘出表，雖無法驗證，但個人有點懷疑；

3、潤乾：12s（多次測試）左右，（取數 + 報表展現）。–因資料處理在集算器已完成，所以報表幾乎無計算，報表計算及生成 html（大概是 20 行 +35 列的單元格）基本不佔用時間。