hibernate3.0发现在海量数据表中查询很慢 ，不在于问题，在于解决问题的思路啊，学习了

使用hibernate3.0，发现在海量数据表中查询很慢
比如一张表，有670万条数据左右， 经过我的测试

使用Expression.eq做条件
当字段类型为int时，字段没有建索引，查询很慢，建了索引，查询就很快

使用Expression.eq Expression.le做条件
当字段类型为string时，字段加了索引，查询需要5到6分钟，字段不加索引，估计没法查

使用Expression.sql做条件
字段没有建索引，查询很慢，建了索引，不管字段是什么类型，查询都很快

难道在面对海量数据查询时，就不能用Expression.eq Expression.le方式加条件，只能用sql方式？？为什么？？

补充：

看了后面的回帖，我先感谢大部分兄弟对我的问题表示关注，为此问题寻求答案表示感谢！

然而对1、2个恶语相伤的朋友表示无语，我不是在抱怨什么，我只是在寻求问题的根源和解决办法，难道每个上来发帖的人都是技术高手，没有问题？？

对此问题
1、有些兄弟说，是不是没建索引，我觉得帖写的挺明白的，我对有无建索引都有描述，而且我当然也明白大量数据中查询当然要建索引的道理

2、返回的数据是否也是海量的，这个怪我没说清楚，我设置的查询条件，返回的数据只有不到20条左右，所以不存在构建海量对象照成的速度慢问题，而且如果真是返回大量的数据，估计不止是速度慢的问题，outofmemory的异常也发生了

我的环境说明下：
hibernate3  
MS SQLServer 2000
驱动是：jtds-1.2.2

我详细说明下我的问题：
比如查ddbjh表，表中字段大概30个，其中对SPDH(数据库是nvarchar类型，设定50长度)字段做条件查询，ddbjh表已对SPDH加了索引

写法一、
Criteria criteria = session.createCriteria(NDdbjh.class);
criteria.add(Expression.ge("SPDH", "11"));
criteria.add(Expression.le("SPDH", "55"));
List<NDdbjh> list = criteria.list();
查询非常慢，大概要5到6分钟

写法二、
Criteria criteria = session.createCriteria(NDdbjh.class);
criteria.add(Expression.sql("'11' <= SPDH and SPDH <= '55'"));
List<NDdbjh> list = criteria.list();
查询很快，第一次查大概不到300ms，第二次以后，几乎在1、20ms左右，非常快

我就不明白，为什么条件一样，只是写法不一样，返回数据不到20条，查询速度的差异怎么这么大？？希望大家再根据我的具体情况，给点意见，谢谢！

补充：

有很多兄弟说要看打印的sql，我把hibernate的sql开关打开了，打印sql如下：

方式一、
criteria.add(Expression.ge("SPDH", "11"));
criteria.add(Expression.le("SPDH", "55"));

hibernate日志显示的sql是:
select [字段略] from NDDBJH this_ where this_.SPDH>=? and this_.SPDH<=?

MS SQLServer2000事件探查器工具显示的内容是：
declare @P1 int
set @P1=1
exec sp_prepare @P1 output, N'@P0 nvarchar(4000),@P1 nvarchar(4000)', N'select [字段略] from NDDBJH this_ where this_.SPDH>= @P0  and this_.SPDH<= @P1 ', 1
select @P1

方式二、
criteria.add(Expression.sql("'11' <= SPDH and SPDH <= '55'"));

hibernate日志显示的sql是：
select [字段略] from NDDBJH this_ where '11' <= SPDH and SPDH <= '55'

MS SQLServer2000事件探查器工具显示的内容是：
declare @P1 int
set @P1=1
exec sp_prepare @P1 output, N'', N'select [字段略] from NDDBJH this_ where ''11'' <= SPDH and SPDH <= ''55''', 1
select @P1

两种查询方式不至于相差了5、6分钟这么大差别吧？

补充：

ddbjh表没有任何表关联

补充：

按照zhizhesky提议，使用jdbc的Statement 和 PreparedStatement分别查，发现了问题
Statement 方式很快，查询的结果且是按索引排序返回的
PreparedStatement 方式就很慢，查询的结果是按数据库上呈现的顺序返回的，索引没起作用，这是为何？？怎么解决呢？

补充：

现在基本能确定是数据库问题，只是不知怎么去优化或设置数据，才能达到在PreparedStatement方式下查询，提高速度？？
总结下问题：
表中有670万条数据，其中SPDH字段是nvarchar(50)类型的，表中对改字段已做索引，另外ID字段是主键，默认是聚合索引，在使用PreparedStatement 方式去查询，非常慢，查询的结果是按数据库上呈现的顺序返回的，似乎索引没起到作用，这该如何去解决呢？请大家帮忙，谢谢了！

补充：

总算对这个问题有了突破性的结果，的确是数据库驱动有问题，我居然从来没想过这个问题，非常感谢 强强爱妍妍 要我换数据库驱动测试。
现在问题又来了：我用的数据库是MS SQLServer2000, 驱动用的jtds1.2.5(最新版本了)，用PreparedStatement方式查询海量数据就有问题， 而如果用微软自带的驱动，这个帖子的问题倒是没有，但我记得当初也是因为有别的bug（不记得是什么了），才选择jtds的，这下两个驱动都有问题，难道我要放弃使用MS SQLServer2000？？