Hibernate2 Like搜索Query#list()速度奇慢的怪问题

海诗美妆 2009-10-30 12:29:50

Like搜索例如select * from xxxx where like 'xxx%'

如果是搜索例如 'a%'，搜索结果多的时候速度倒还可以，
如果是搜索例如'abcd%'，搜索结果少的时候，处理速度反而会变得非常慢。
不知道哪位知道这是什么原因。

以下是日志摘要：
主要看第三行和第四行得执行时间

2009-10-23 20:08:34,627 DEBUG Loader.java:480 result row: 464383, 784940, 786978
2009-10-23 20:08:34,628 DEBUG Loader.java:480 result row: 464316, 784940, 786978
2009-10-23 20:08:34,629 DEBUG Loader.java:480 result row: 464049, 784940, 786978
2009-10-23 20:08:55,964 DEBUG Loader.java:480 result row: 463905, 784940, 786978
2009-10-23 20:08:55,966 DEBUG Loader.java:480 result row: 463895, 784940, 786978

...全文

284 21 打赏收藏举报

写回复

用AI写文章

21 条回复

切换为时间正序

请发表友善的回复…

发表回复

海诗美妆 2009-11-06

打赏
举报

[Quote=引用 20 楼 apollo_ts 的回复:]
这个需要一个公平的测试才行呀！

一般list执行是：

断定是否flushMode和cacheMode模式。你把这个设置都set null，这样测试出的信息公平一些。

然后都设为只读事务。

之后把检索前后的经过时间发出来，只要这个时间段信息。记住都要SQLQuery的接口实现。

[/Quote]

多谢提醒,结贴啦!

APOLLO_TS 2009-11-05

打赏
举报

这个需要一个公平的测试才行呀！

一般list执行是：

断定是否flushMode和cacheMode模式。你把这个设置都set null，这样测试出的信息公平一些。

然后都设为只读事务。

之后把检索前后的经过时间发出来，只要这个时间段信息。记住都要SQLQuery的接口实现。

海诗美妆 2009-11-05

打赏
举报

没人遇到过吗？

海诗美妆 2009-11-02

打赏
举报

[Quote=引用 17 楼 preferme 的回复:]
我不知道楼主用什么方法可以肯定一条SQL查询语句所花费的时间的。
我一般在开发过程中，如果遇到像楼主这样的问题。
首先，会用第三方软件执行一下这个查询语句（如果是SQL Server就用查询分析器，MySQL就用SQLyog），这样可以排除是否是Hibernate而导致的速度缓慢。
其次，如果第三方软件确实执行很快。那么，就要看看，你查询所涉及的类里面是否存在其他相关联的类，有那个什么延迟加载之类的设置。当然，这样找起来可能会显得比较盲目，范围比较大。
所以，推荐楼主使用p6spy辅助查看，到底Hibernate向数据库发送了哪些SQL语句，这样找起来，效率可能会更高一些。

上面啰嗦那么多，并没有瞧不起楼主的意思，只是依照的我的个人经验而谈。
当然，楼主遇到的情况很可能和我所遇到的情况不同，因而，我所说的就成为了废话。
但，目的也都是为了帮楼主尽快解决问题。
15楼所指的“问题”并非查询结果不正确，而是指查询过于缓慢。当然，楼主强调了，没有这个问题。
[/Quote]

Oralce 10g SQL Plus:

SQL> set lines 200
SQL> col plan_plus_exp format a200
SQL> set pages 0
SQL> set autotrace on
SQL> select num from test2 where num = 1;

冰思雨 2009-11-01

打赏
举报

我不知道楼主用什么方法可以肯定一条SQL查询语句所花费的时间的。
我一般在开发过程中，如果遇到像楼主这样的问题。
首先，会用第三方软件执行一下这个查询语句（如果是SQL Server就用查询分析器，MySQL就用SQLyog），这样可以排除是否是Hibernate而导致的速度缓慢。
其次，如果第三方软件确实执行很快。那么，就要看看，你查询所涉及的类里面是否存在其他相关联的类，有那个什么延迟加载之类的设置。当然，这样找起来可能会显得比较盲目，范围比较大。
所以，推荐楼主使用p6spy辅助查看，到底Hibernate向数据库发送了哪些SQL语句，这样找起来，效率可能会更高一些。

上面啰嗦那么多，并没有瞧不起楼主的意思，只是依照的我的个人经验而谈。
当然，楼主遇到的情况很可能和我所遇到的情况不同，因而，我所说的就成为了废话。
但，目的也都是为了帮楼主尽快解决问题。
15楼所指的“问题”并非查询结果不正确，而是指查询过于缓慢。当然，楼主强调了，没有这个问题。

海诗美妆 2009-11-01

打赏
举报

[Quote=引用 15 楼 preferme 的回复:]
楼主提出的原因，我已经解释清楚了。至于怎么解决，一来楼主也没问，再者，主要也是要看实际的数据才能有更好的方法。楼上的几位兄弟所提的方法，都不错。楼主可以参考一下。
[/Quote]

上面已经重复n遍了，SQL没有问题，执行速度很快。
相反搜索结构少的时候，反而速度变慢。

数据库访问这边肯定没有问题，问题在java/hibernate处理这边，
但是具体什么原因我实在查不出来，
所以把日志贴上来，问问有没有碰到过类似问题的朋友。

select是否有问题，是要看执行计划的，不需要问别人。况且，如果SQL的问题，我也不会往这里发。

冰思雨 2009-10-31

打赏
举报

呵呵。楼主可能忽略了一个问题。
就是SQL语句查询效率的问题。

一般我们进行查询语句的编程时，都应该考虑查询的结果集的相关问题。
比如结果集的大小是否会使内存暴掉，或者程序由于数据量过于庞大而运行缓慢。
但是，楼主有没有想过，你的查询语句，执行起来需要多少时间呢？

一般在用查询语句的时候，如果结果只有1条记录的时候，倒是很好处理的事情。
但，如果查询的结果，其记录的条数不确定的时候，我们怎么办？
分页技术，就是一个很好的技术。当然，这是将整体拆成很小的部分，分别处理的一种情况。
我们有时候，也只是想，随便查他几条记录就行。
那么，SQL Server的 select top以及MySQL的limit就有了用武之地了。

楼主的like语句并没有问题。问题在于，您所查询的表太大了，里面的记录太多了。
一条like语句，在没有限制的情况下，他会查询表里面的所有数据，从第一条一直到最后一条，他都要进行匹配。

再看“a%”和“abc%”，他们的区别就是在对每一条记录进行比较的时候，“abc%”的比较次数要不少于“a%”的比较次数。因为，像“ab”、“abcaa”这样的字符串，“a%”每个只比较一次，而，“abc%”他第一个要比较2次，第二个要比较3次才能得出结果。
这就是查询结果少反而费时间的原因。

楼主提出的原因，我已经解释清楚了。至于怎么解决，一来楼主也没问，再者，主要也是要看实际的数据才能有更好的方法。楼上的几位兄弟所提的方法，都不错。楼主可以参考一下。