① 使用sql Server CE查詢10000條記錄所需的時間是多少
1.查詢消耗時間影響因素很多：編寫的語句，查詢的方式，外部環境CPU，內存等等。
2.查詢10000條數據記錄平均消耗時間應該在0.01~0.02秒以下。
② SQL查詢時間多長為正常，誰能告訴我這個查詢如何優化
你這個時間短不了，你自己數數有多少個join？用join就是笛卡爾積的運算了。可費時間了。
優化不好說，沒看過完整表和過程。不過通常對付join來說，可以用in子集的方式找比如說
select * from 表1
where id in (select id form 表2 )
這種查詢要比
select * from 表1 left join 表2
on 表1.id=表2.id
來的要速度。
或者加索引到連接列上。在要不然就加大硬體。
③ sql sever 2005 資料庫，查詢100萬條數據用多少時間比較合理
看你什麼樣的應用，如果是實時，當然是越短越好。如果是統計一類非實時項目，10秒以內客戶應該都能接受。
不過，一條查詢就需要100萬條數據清單，這樣的應用恐怕很難滿足。稍微多兩個客戶，伺服器就無法響應了。而且還要考慮網路傳輸，100萬條，數據量是非常大的，哪怕你的欄位不是很多。
④ 求sql 查詢語句加where 和 ORDER BY 後耗時優化
目測題主寫出的這幾條語句未發現特別消耗系統資源的運算，都是一些規范的寫法，可以說沒有什麼可以優化的，如果需要讓它們運行的更快一些應該從設置索引這個方向去解決。
最前兩條語句無篩選、用欄位`houseid`排序運算，毫秒級耗時都非常快，該欄位應該建立了索引並被利用。
語句1. 用欄位infocat=1進行篩選，盡管還是用欄位`houseid`排序運算，但是耗時立即增加到數百毫秒級，顯然欄位`infocat`沒有可被利用的索引。建議為欄位infocat添加索引，這樣相信此語句的運行速度會大幅提高。
語句2. 用欄位`edittime`排序，無篩選，耗時較用欄位`houseid`排序的耗時從毫秒級大幅增加到3百多毫秒，顯然欄位`edittime`也無可利用的索引。如為此欄位添加索引，此語句的運行速度可提高一個數量級。
語句3跟語句1.情況一樣，如果欄位`infocat`有索引，其運行速度可大幅提高。如果篩選後返回的行特別多，那麼再為欄位`edittime`加索引可為提高運行速度加分（篩選後如返回的行數目有限，則欄位`edittime`有無索引對提高速度幫助作用不大）。
⑤ SQL查詢一塊查，和分開查的時間一樣嗎
你好，很高興回答你的問題。
這兩張查詢方式的耗時是不一樣的。
如果索引合適，數據量也不是太大的話，一個sql執行的耗時是遠小於按天查詢執行31個sql的耗時的。
如果有幫助到你，請點擊採納。
⑥ 在asp環境中，sql查詢一個八萬條記錄的表正常情況需要多長時間
要看什麼資料庫了，access資料庫，大概1秒。
sql server的話，1秒內完成。
⑦ 在資料庫中查看一個SQL執行一次耗時多少
下面這種是SQL Server中比較簡單的查詢SQL語句執行時間方法源碼天空
，通過查詢前的時間和查詢後的時間差來計算的：
declare @begin_date datetime
declare @end_date datetime
select @begin_date = getdate()
select @end_date = getdate()
select datediff(ms,@begin_date,@end_date) as '用時/毫秒'
2：下面這種方法比較全面，將執行每個語句時採取的步驟作為行集返回，通過層次結構樹的形式展示出來
set statistics profile on
set statistics io on
set statistics time ongo
<這里寫上你的語句...go
set statistics profile off
⑧ SQL的查詢速度問題
300條數據對於SQL2000的讀操作來說應該是毫秒級就完成的。
你的這個問題，可能出在應用程序、網路質量上。
SQL2000的排查方法：
SQL2000的可能性小，但是為了保險起見，你可以把SQL2000伺服器重新啟動一次，然後在查詢分析器中執行你的SQL語句，看執行時間，若是慢，就要用Ctrl+L來檢查是SQL語句中那句話影響了效率，若是還沒有找到原因，建議你盡快轉移你的SQL2000的資料庫，可能是你SQL2000資料庫所在的硬碟有壞道了，小心丟失數據！！
DELPHI的排查方法：
看不到你的程序，所以你自己檢查好了。
呵呵，希望對你有幫助。
⑨ 如何解決SQL查詢速度太慢
1. 執行計劃中明明有使用到索引，為什麼執行還是這么慢？
2. 執行計劃中顯示掃描行數為 644，為什麼 slow log 中顯示 100 多萬行？
a. 我們先看執行計劃，選擇的索引 「INDX_BIOM_ELOCK_TASK3(TASK_ID)」。結合 sql 來看，因為有 "ORDER BY TASK_ID DESC" 子句，排序通常很慢，如果使用了文件排序性能會更差，優化器選擇這個索引避免了排序。
那為什麼不選 possible_keys:INDX_BIOM_ELOCK_TASK 呢？原因也很簡單，TASK_DATE 欄位區分度太低了，走這個索引需要掃描的行數很大，而且還要進行額外的排序，優化器綜合判斷代價更大，所以就不選這個索引了。不過如果我們強制選擇這個索引（用 force index 語法），會看到 SQL 執行速度更快少於 10s，那是因為優化器基於代價的原則並不等價於執行速度的快慢；
b. 再看執行計劃中的 type:index，"index" 代表 「全索引掃描」，其實和全表掃描差不多，只是掃描的時候是按照索引次序進行而不是行，主要優點就是避免了排序，但是開銷仍然非常大。
Extra:Using where 也意味著掃描完索引後還需要回表進行篩選。一般來說，得保證 type 至少達到 range 級別，最好能達到 ref。
在第 2 點中提到的「慢日誌記錄Rows_examined: 1161559，看起來是全表掃描」，這里更正為「全索引掃描」，掃描行數確實等於表的行數；
c. 關於執行計劃中：「rows：644」，其實這個只是估算值，並不準確，我們分析慢 SQL 時判斷准確的掃描行數應該以 slow log 中的 Rows_examined 為准。
4. 優化建議：添加組合索引 IDX_REL_DEVID_TASK_ID(REL_DEVID,TASK_ID)
優化過程：
TASK_DATE 欄位存在索引，但是選擇度很低，優化器不會走這個索引，建議後續可以刪除這個索引：
select count(*),count(distinct TASK_DATE) from T_BIOMA_ELOCK_TASK;+------------+---------------------------+| count(*) | count(distinct TASK_DATE) |+------------+---------------------------+| 1161559 | 223 |+------------+---------------------------+
在這個 sql 中 REL_DEVID 欄位從命名上看選擇度較高，通過下面 sql 來檢驗確實如此：
select count(*),count(distinct REL_DEVID) from T_BIOMA_ELOCK_TASK;+----------+---------------------------+| count(*) | count(distinct REL_DEVID) |+----------+---------------------------+| 1161559 | 62235 |+----------+---------------------------+
由於有排序，所以得把 task_id 也加入到新建的索引中，REL_DEVID,task_id 組合選擇度 100%：
select count(*),count(distinct REL_DEVID,task_id) from T_BIOMA_ELOCK_TASK;+----------+-----------------------------------+| count(*) | count(distinct REL_DEVID,task_id) |+----------+-----------------------------------+| 1161559 | 1161559 |+----------+-----------------------------------+
在測試環境添加 REL_DEVID，TASK_ID 組合索引，測試 sql 性能：alter table T_BIOMA_ELOCK_TASK add index idx_REL_DEVID_TASK_ID(REL_DEVID,TASK_ID);
添加索引後執行計劃：
這里還要注意一點「隱式轉換」：REL_DEVID 欄位數據類型為 varchar，需要在 sql 中加引號：AND T.REL_DEVID = 000000025xxx >> AND T.REL_DEVID = '000000025xxx'
執行時間從 10s+ 降到 毫秒級別：
1 row in set (0.00 sec)
結論
一個典型的 order by 查詢的優化，添加更合適的索引可以避免性能問題：執行計劃使用索引並不意味著就能執行快。
⑩ SQL怎麼看一個查詢語句用了多少時間
mssql 裡面執行完查詢語句後，所有數據顯示後，下面左邊會有個「查詢已成功執行」，最右邊是顯示總行數，緊挨著就是顯示執行的時間了，如「00：00：01」 ，這個程序執行了一秒。