这里的环境： 我们为基于嵌入式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