hibernate3.0發如今海量數據表中查詢很慢 ，不在於問題，在於解決問題的思路啊，學習了

使用hibernate3.0，發如今海量數據表中查詢很慢
好比一張表，有670萬條數據左右， 通過個人測試

使用Expression.eq作條件
當字段類型爲int時，字段沒有建索引，查詢很慢，建了索引，查詢就很快

使用Expression.eq Expression.le作條件
當字段類型爲string時，字段加了索引，查詢須要5到6分鐘，字段不加索引，估計無法查

使用Expression.sql作條件
字段沒有建索引，查詢很慢，建了索引，無論字段是什麼類型，查詢都很快

難道在面對海量數據查詢時，就不能用Expression.eq Expression.le方式加條件，只能用sql方式？？爲何？？

補充：

看了後面的回帖，我先感謝大部分兄弟對個人問題表示關注，爲此問題尋求答案表示感謝！

然而對一、2個惡語相傷的朋友表示無語，我不是在抱怨什麼，我只是在尋求問題的根源和解決辦法，難道每一個上來發帖的人都是技術高手，沒有問題？？

對此問題
一、有些兄弟說，是否是沒建索引，我以爲帖寫的挺明白的，我對有無建索引都有描述，並且我固然也明白大量數據中查詢固然要建索引的道理

二、返回的數據是否也是海量的，這個怪我沒說清楚，我設置的查詢條件，返回的數據只有不到20條左右，因此不存在構建海量對象照成的速度慢問題，並且若是真是返回大量的數據，估計不止是速度慢的問題，outofmemory的異常也發生了

個人環境說明下：
hibernate3  
MS SQLServer 2000
驅動是：jtds-1.2.2

我詳細說明下個人問題：
好比查ddbjh表，表中字段大概30個，其中對SPDH(數據庫是nvarchar類型，設定50長度)字段作條件查詢，ddbjh表已對SPDH加了索引

寫法1、
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分鐘

寫法2、
Criteria criteria = session.createCriteria(NDdbjh.class);
criteria.add(Expression.sql("'11' <= SPDH and SPDH <= '55'"));
List<NDdbjh> list = criteria.list();
查詢很快，第一次查大概不到300ms，第二次之後，幾乎在一、20ms左右，很是快

我就不明白，爲何條件同樣，只是寫法不同，返回數據不到20條，查詢速度的差別怎麼這麼大？？但願你們再根據個人具體狀況，給點意見，謝謝！

補充：

有不少兄弟說要看打印的sql，我把hibernate的sql開關打開了，打印sql以下：

方式1、
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

方式2、
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

兩種查詢方式不至於相差了五、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？？