這裏的環境： 我們爲基於嵌入式h2數據庫的客戶編寫了一個應用程序，它在執行之前升級到最新版本試驗。該數據庫由29個表和26個視圖組成。在26個視圖中，只有8個在Java中真正被「使用」，將視圖映射爲hibernate到pojos。其他視圖僅僅是爲其他視圖進行背景計算，如彙總某些值然後按某個列進行分組。 在這些視圖中進行了很多計算。我們決定不用java計算，因爲您可以使用您最喜歡的工具（例如h2 console）輕鬆檢查數據庫表，查看計算中是否有任何錯誤。由於這個事實，在這些視圖中有很多「CASE WHEN ... END」語句，因爲一旦該行中的單個列爲NULL，hibernate總是返回所有列中具有NULL值的整行。我們從來沒有能夠把我們的手指也放在這個問題上......但是，由於這個事實，我們在計算中也有分歧，所以我們無論如何都需要檢查NULL，0和0.0。 視圖是「堆疊」的，因爲有些中間值有時用在別的地方。但是在最後一個視圖「下面」總是存在一個「堆疊」的7個視圖，這也是基於另一個視圖使用6個視圖的「堆棧」。一些觀點是相同的一些沒有。我在擴展我使用視圖的基於h2的java應用程序時遇到了問題
現在，來這裏的問題： 當插入的記錄，在約一對夫婦（如20）到數據庫中的「有趣的」表一個視圖提供數據（4個彙總行）。 400毫秒。對我們來說這沒問題。 將數據放大到大約500-2000條記錄（特殊視圖（提供大約25個彙總行））需要花費一個多小時（1小時）才能傳輸數據。 該機器可以是具有8GB RAM（-Xmx2G和-Xms1G）CPU 2,66GHz（Intel（R）Core（TM）2 Quad CPU Q8400 @ 2.66GHz）的Linux或具有4GB RAM的RAM（-Xmx1G -Xms512m）CPU未知但可能是單核/雙核@ 2GHz。
我到目前爲止的分析： 我追溯了應用程序的內存使用情況，似乎並不是主要問題。 在長時間運行的查詢過程中查看堆棧跟蹤，發現我的入口點（有時）達到（！）低於100個級別的堆棧深度，並進入休眠getEntityManager（）。createQuery（getCriteriaQuery（））。getResultList（）。顯而易見的「耗時」是org.h2.table.TableFilter/Table/TableView.getBestPlanItem和org.h2.table.Plan.calculateCost以及org.h2.index.ViewIndex.getCost。 我檢查了所有視圖中缺失索引的所有聯接，發現了一個，添加了，但沒有成功。
我的測試： 我傳輸的所有數據和架構成一個PostgreSQL（8.1）在同一臺Linux機器上（香草未改動）和運行測試有（做任何vaccuum或重新編制前！），結果是壓倒性的：約。 6秒。對於在h2上花費大約1小時的相同數據的相同觀點來看。
現在我真的不想切換我的數據庫，但除非任何人有一個好主意，這將是最終的選擇...
備註： 在我發現事情是這樣的：當 檢查h2的information_schema中的視圖，我可以看到他正在做一些分析視圖本身的工作。 我的sql腳本中的所有視圖都在20行和120行之間（大約）。信息模式範圍從2KBytes到3MBytes（即兆字節）的「編譯」視圖從上面的接近400k ... 也許這也是一個問題......好吧，這就是所有人。我很優雅的任何幫助。我願意切換數據庫，因爲我們在整個地方都使用hibernate和CriteriaQuery，所以唯一的工作就是切換jdbc連接器，更改視圖中的一些代碼（已經完成，但必須在生產之前檢查兩次）以及安裝PostgreSQL或MSDE在客戶臺式電腦（irk），這將導致可能發生的其他不需要的錯誤，可能會發生，因爲MS更新可能會離開MSDE破壞或數據庫將無法啓動，因爲任何原因...
關心， Holger