命名查询的 h2 数据库性能问题答案

【问题标题】：h2 Database performance issues with Named Query命名查询的 h2 数据库性能问题
【发布时间】：2018-09-29 12:07:20
【问题描述】：

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

我们的应用程序运行在

Windows 客户端
Jetty 网络服务器
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 毫秒）。

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

【问题讨论】：

您有两种情况的查询计划吗？它们是一样的吗？
更新后您是否尝试在数据库上运行ANALYZE？如果统计信息被正在更新的数据抛出，计划者可能会选择一个比必要的更糟糕的计划。如果ANALYZE之后查询又快了，根本原因是DB统计。
查询总是一样的。我不能做ANALYZE，因为我得到了Error: Syntax error in SQL statement "ANALYZE TABLE TECDOC_OBJECTS SAMPLE_SIZE[*] 0"; expected "integer"; SQL statement: -> stackoverflow.com/questions/44794115/analyze-table-syntax-error
它是否适用于 ANALYZE TABLE TECDOC_OBJECTS 而无需指定样本大小？整个分析命令不太可能被破坏。
普通的ANALYZE怎么样？这将需要一段时间，但如果查询在此之后立即运行（我怀疑它确实如此），它仍然是统计信息。然后你只需要升级你的H2并在更新后对表进行分析。

标签： java performance h2 named-query

【解决方案1】：

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

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

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

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

再说一次，我喜欢 H2，但我认为你会开始在这个级别的数据上遇到越来越多的性能问题。

H2 的 SQL 优化器至少可以说是晦涩难懂的，而且很难阅读。而且，要让它改变主意（让它改变计划）也不是件容易的事。

【讨论】：

感谢您的回答，我经常达到 H2 的极限。目前我们在短期内切换DB并不是那么容易。对于未来，我肯定会考虑它。我还发布了一个关于 stackoverflow.com/questions/50060278/… 的简单问题 h2

【解决方案2】：

我answered this question，在那里我明确提出了一个 H2 特定问题。

我现在在最后删除了一些组合索引，现在性能又更快了。

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

USE INDEX 有一个选项，但是这个只有在 1.4.194 之后才有，这也使得其他一些查询非常慢，甚至由于内存不足而无法执行。

【讨论】：