h2命名查询

Question

只是一些预先信息。我们使用的H2文件数据库已经大约15 GB。

我们的应用程序在

上运行

• Windows客户端
• Jetty Webserver
• H2文件数据库

每次需要在客户端更新数据时，用户将获得带有XML文件的zip文件。 XML文件将导入到DB，或者xml文件具有标记“delete”，并且将删除DB中的条目。每个zip文件的导入都有一个数据版本。导入是使用Java手动完成的。 XML文件被反序列化为POJO并映射到我们的域实体。

有了这个，我们还可以将所有数据全部导入数据库（只需要8小时）。

致我们的问题：

发生问题的表格大约有290,000行。

结构是：

我们有一个命名查询：

    @NamedNativeQuery(name="getRawTecdocWithMaxVersionAndGivenLocale", 
            query = "select tdo.tecdoc_guid as guid, tdo.tecdoc_locale as locale , tdo.tecdoc_version as version, tdo.data as data "
                    + " from TECDOC_OBJECTS tdo "
                    + " left outer join TECDOC_OBJECTS tdo1 "
                    + " on (tdo.tecdoc_guid = tdo1.tecdoc_guid and tdo.tecdoc_locale = tdo1.tecdoc_locale and tdo.tecdoc_version < tdo1.tecdoc_version) "
                    + " where tdo1.id is null " 
                        +  " and tdo.tecdoc_guid in ( ?1 ) "
                        +  " and tdo.tecdoc_locale = ?2 ",
            resultSetMapping = "rawTecdocs")

数据更新（zip文件导入）后1秒内变得非常慢。给定guid的实际查询在数据更新后没有改变。

我们对所选的列有索引。

奇怪的地方

如果我们用完整更新填充我们的数据库（通过XML导入的所有15GB数据），查询似乎再次“快速”（20-50毫秒）。

也许有人暗示我/我们要克服这个问题？

Answer 1

只是我的两分钱：一个非常个人的意见。

  

我们使用的H2文件数据库已经大约15 GB。

我喜欢H2，是的，我喜欢。

话虽如此，我个人认为每个数据库都有自己的利基，也许15 GB略高于H2的细分市场。当您在H2中达到1 GB标记时，应考虑切换到另一个数据库。如果你喜欢免费数据库，你可以开始认真看待PostgreSQL和MariaDB。

同样，我喜欢H2，但我认为这个级别的数据会开始出现越来越多的性能问题。

H2的SQL优化器至少可以说是难以理解，并且难以阅读。此外，让它改变主意（让它改变计划）并不容易。

Answer 2

我answered this question，我明确询问H2特定问题。

我现在删除了一些组合索引，现在性能再次更快。

与某些客户端上的ANALYZE一样，它解决了一些问题，使其（或其他部分）变得更糟。

USE INDEX有一个选项，但这仅在1.4.194之后可用，由于内存不足，这也使得其他一些查询速度很慢甚至无法执行。