hsqldb的一次优化经历--update语句里不能再写多余的select

原始发表时间：2009-06-18

 

    环境 -- hsqldb 1.8.0.10，sun jdk 1.6
    在hsqldb中操作800条记录，执行35个update语句，每个update语句需要耗时2秒左右。
    查询官方论坛得知，如果使用PreparedStatement，10000左右的update操作也不需要这么久的时间（具体时间大家可以去官网查一下，现在不太记得，就不乱讲……）

    但是我的情况和官网上的示例不具备参考性，35条update操作语句结构都是不相同的，而非是可以进行预编译的参数部分。
    我的update语句示例如下：

update
    DATA_TABLE p
set
    p.USER_DEFINET =  (
         select USER_DEF0 +  ... + USER_DEF7
         from DATA_TABLE c
         where p.emp_id = c.emp_id and p.cmp_id = c.cmp_id
    )
where
    p.month = '08'
    and p.cmp_id in (
        '8a95802321afc7850121afc794e5036b'
    )

    这是对一个单位的800多个人员的合计项的计算SQL语句，每个单位的不同人员在该表中只有一条记录。这样一条语句在hsqldb中加上相关的索引，而后执行仍需要2秒左右，最快也就1.6秒。

    其实仔细观察一下不难发现一个问题，该SQL多做了一个select查询操作。这样会导致无畏的查询动作，修改一下：

update
    DATA_TABLE p
set
    p.USER_DEFINET =  USER_DEF0 +  ... + USER_DEF7
where
    p.month = '08'
    and p.cmp_id in (
        '8a95802321afc7850121afc794e5036b'
    )

    这条语句执行的稳定耗时在 0.15秒 左右。

总结：
    急于否定产品级别的文件型数据库，想当然的以为是hsqldb的性能问题，于是乎，在论坛中搜索都是用“hsqldb performance”这样的关键字，结果白白耗费一天的时间，竟然找到的问题就是update操作的SQL中多了一个select操作。
    目前为止使用hsqldb的除了OpenOffice，还有Jira等软件（详见官方网站上的介绍）。