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
如果是搜索例如'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
生成后的SQL肯定没有问题，查询速度也很快。
速度不应该相差很大，要么都很慢，要么都不慢每次运行都是这样么？
用全文索引
http://topic.csdn.net/t/20040821/10/3295983.html
把'a%' 'abcd%' 的sql直接在数据库跑下看看
SQL没有问题，速度都很快
就是SQL语句查询效率的问题。一般我们进行查询语句的编程时，都应该考虑查询的结果集的相关问题。
比如结果集的大小是否会使内存暴掉，或者程序由于数据量过于庞大而运行缓慢。
但是，楼主有没有想过，你的查询语句，执行起来需要多少时间呢 ？一般在用查询语句的时候，如果结果只有1条记录的时候，倒是很好处理的事情。
但，如果查询的结果，其记录的条数不确定的时候，我们怎么办？
分页技术，就是一个很好的技术。当然，这是将整体拆成很小的部分，分别处理的一种情况。
我们有时候，也只是想，随便查他几条记录就行。
那么，SQL Server的 select top以及MySQL的limit就有了用武之地了。楼主的like语句并没有问题。问题在于，您所查询的表太大了，里面的记录太多了。
一条like语句，在没有限制的情况下，他会查询表里面的所有数据，从第一条一直到最后一条，他都要进行匹配。再看“a%”和“abc%”，他们的区别就是在对每一条记录进行比较的时候，“abc%”的比较次数要不少于“a%”的比较次数。因为，像“ab”、“abcaa”这样的字符串，“a%”每个只比较一次，而，“abc%”他第一个要比较2次，第二个要比较3次才能得出结果。
这就是查询结果少反而费时间的原因。楼主提出的原因，我已经解释清楚了。至于怎么解决，一来楼主也没问，再者，主要也是要看实际的数据才能有更好的方法。楼上的几位兄弟所提的方法，都不错。楼主可以参考一下。
上面已经重复n遍了，SQL没有问题，执行速度很快。
相反搜索结构少的时候，反而速度变慢。数据库访问这边肯定没有问题，问题在java/hibernate处理这边，
但是具体什么原因我实在查不出来，
所以把日志贴上来，问问有没有碰到过类似问题的朋友。
select是否有问题，是要看执行计划的，不需要问别人。况且，如果SQL的问题，我也不会往这里发。
我一般在开发过程中，如果遇到像楼主这样的问题。
首先，会用第三方软件执行一下这个查询语句（如果是SQL Server就用查询分析器，MySQL就用SQLyog），这样可以排除是否是Hibernate而导致的速度缓慢。
其次，如果第三方软件确实执行很快。那么，就要看看，你查询所涉及的类里面是否存在其他相关联的类，有那个什么延迟加载之类的设置。当然，这样找起来可能会显得比较盲目，范围比较大。
所以，推荐楼主使用p6spy辅助查看，到底Hibernate向数据库发送了哪些SQL语句，这样找起来，效率可能会更高一些。上面啰嗦那么多，并没有瞧不起楼主的意思，只是依照的我的个人经验而谈。
当然，楼主遇到的情况很可能和我所遇到的情况不同，因而，我所说的就成为了废话。
但，目的也都是为了帮楼主尽快解决问题。
15楼所指的“问题”并非查询结果不正确，而是指查询过于缓慢。当然，楼主强调了，没有这个问题。
SQL> col plan_plus_exp format a200
SQL> set pages 0
SQL> set autotrace on
SQL> select num from test2 where num = 1;