【问题标题】:H2 (File) Delete PerformanceH2(文件)删除性能
【发布时间】:2016-07-06 07:10:44
【问题描述】:

当涉及到 AUTO-SERVER 模式下的基于文件的 H2 数据库时,我遇到了一些性能问题。我正在使用 H2 版本 1.3.174。该数据库包含一个包含 5 列的表。其中一列是 CLOB,它(平均)每行包含 1 KB 的文本数据。在单线程测试运行中,我插入了 800,000 行,耗时 409 秒——对我来说还可以。我通过以下步骤执行了第二次测试运行:

  1. 从数据库加载前 100 条消息。消息的顺序是通过主键 (NUMBER) 值建立的。
  2. 使用以下语句删除这 100 条消息:DELETE FROM mytable WHERE id IN (...);

这会一直执行到数据库的 790,000 行被删除为止。在我的真实场景中,第 1 步和第 2 步之间会涉及到一些处理。第二次测试运行需要 8.5 小时,在没有负载的快速机器上运行!我观察到,在删除过程中,H2 创建了名称为“mydb.1978734278.38.temp.db”的临时文件,其大小在 24 到 1,300 MB 之间快速变化。

这是预期的行为吗?有什么想法我可能做错了吗?感谢您的帮助!

【问题讨论】:

  • 您是否索引了您的id 列?
  • 嗨,andyf - 是的,ID 列是主键列并且有一个“PRIMARY KEY”索引。
  • 问题可能是您使用的是 CLOB,这会创建临时文件(这会降低性能)
  • 嗯,我认为我不会绕过 CLOB。我可以尝试将数据存储在一个大的 VARCHAR 列中,看看是否有什么不同。我觉得奇怪的是,在第一次测试运行后我没有看到任何临时文件,只有在删除发生时。存储 CLOB 时不应该有临时文件吗?

标签: java database h2


【解决方案1】:

我正在用我的发现回答我自己的问题:

  1. 主要问题是 SELECT 语句,这是由于缺少索引。设置正确的 INDEX 后,SELECT/DELETE 测试运行只需 2 分钟。
  2. 使用 CLOBS 或 LONGVARBINARY 而不是 VARCHAR 时似乎存在空间问题:使用后者时文件大小减半。

【讨论】:

    猜你喜欢
    • 2015-09-18
    • 2022-01-21
    • 1970-01-01
    • 1970-01-01
    • 2018-03-07
    • 2011-08-04
    • 1970-01-01
    • 2016-06-08
    • 1970-01-01
    相关资源
    最近更新 更多