1. sql語句查詢速度是1分鍾慢嗎
這樣的時間程序是有問題了，你這條sql執行需要一分鍾，前台就得等一分鍾，沒有用戶會願意等，現在查詢時間都是毫秒級別的，如果查詢時間實在減不下來，可以做緩存，或者索引
2. sql語句聯合查詢 與 視圖想比較的話，那個效率快，為什麼。
sql效率比較快，存儲過程的好處是不僅快且更安全，但移植性差。視圖可以封裝查詢的復雜性，就像面向對象里類的概念一樣。
3. SQL查詢速度 Select Count(1)
如果null參與聚集運算，則除count(*)之外其它聚集函數都忽略null。
如：
ID DD
1 e
2 null
select count(*) from table --結果是2
select count(DD) from table ---結果是1
有說count(1)效率高，感覺差不多，沒啥區別。
一、關於count的一些謠言：
1、count(*)比count(val)更慢！項目組必須用count(val)，不準用count(*)，誰用扣誰錢！
2、count(*)用不到索引，count(val)才能用到。
3、count(*)是統計出全表的記錄，是吞吐量的操作，肯定用不到索引。
4、count(1)比count(*)的速度快。
二、驗證count(*)和count(val)
1、首先創建一個表，使用count(*)和count(val)查詢比較：
----刪除echo表----
SQL> drop table echo purge;
drop table echo purge
*
第 1 行出現錯誤:
ORA-00942: 表或視圖不存在
----創建一張echo的測試表----
SQL> create table echo as select * from dba_objects;
表已創建。
SQL> update echo set object_id = rownum;
已更新72509行。
SQL> commit;
提交完成。
SQL> set timing on
SQL> set linesize 100
SQL> set autotrace on
SQL> select count(*) from echo;
COUNT(*)
----------
72509
已用時間: 00: 00: 00.01
執行計劃
----------------------------------------------------------
Plan hash value: 99109176
-------------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
-------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 290 (1)| 00:00:04 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | TABLE ACCESS FULL| ECHO | 80064 | 290 (1)| 00:00:04 |
-------------------------------------------------------------------
Note
-----
- dynamic sampling used for this statement (level=2)
統計信息
----------------------------------------------------------
4 recursive calls
0 db block gets
1265 consistent gets
0 physical reads
11060 redo size
425 bytes sent via SQL*Net to client
415 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
SQL> select count(*) from echo;
COUNT(*)
----------
72509
已用時間: 00: 00: 00.01
執行計劃
----------------------------------------------------------
Plan hash value: 99109176
-------------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
-------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 290 (1)| 00:00:04 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | TABLE ACCESS FULL| ECHO | 80064 | 290 (1)| 00:00:04 |
-------------------------------------------------------------------
Note
-----
- dynamic sampling used for this statement (level=2)
統計信息
----------------------------------------------------------
0 recursive calls
0 db block gets
1038 consistent gets
0 physical reads
0 redo size
425 bytes sent via SQL*Net to client
415 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
SQL> select count(object_id) from echo;
COUNT(OBJECT_ID)
----------------
72509
已用時間: 00: 00: 00.01
4. sql server 2008查詢速度快嗎
有沒有索引、數據量、同時連接數、查詢語句的優化等都會對查詢速度有影響的，如果只是簡單的查詢速度還是很快的
5. SQL的查詢速度問題
300條數據對於SQL2000的讀操作來說應該是毫秒級就完成的。
你的這個問題，可能出在應用程序、網路質量上。
SQL2000的排查方法：
SQL2000的可能性小，但是為了保險起見，你可以把SQL2000伺服器重新啟動一次，然後在查詢分析器中執行你的SQL語句，看執行時間，若是慢，就要用Ctrl+L來檢查是SQL語句中那句話影響了效率，若是還沒有找到原因，建議你盡快轉移你的SQL2000的資料庫，可能是你SQL2000資料庫所在的硬碟有壞道了，小心丟失數據！！
DELPHI的排查方法：
看不到你的程序，所以你自己檢查好了。
呵呵，希望對你有幫助。
6. sql查詢速度
呵呵，這個問題很有趣不是嗎？
上面的同志們只是給出一些建議，以我的經驗來看（oracle），
如果數據量較大，索引的重復量盡量避免，最好的方式是建立非業務id（最好使用自增或是序列），把這個id建立索引。
你的最大的問題就是，建立了索引後，索引列必須出現在where中，否則索引就白白建立了，比如你的id是從1一直到383000，那麼你的語句可以寫成
select * from hr_worktime where id>-1
還有就是，where條件中避免出現!=,or,between,等東西，否則索引實效。
如果對您有幫助，請記得採納為滿意答案，謝謝！祝您生活愉快！
vaela
7. SQL連表查詢跟一個個表查詢那個快各有什麼優點和缺點
SQL鏈接表查詢稱為聯合查詢，表查詢是單個查詢。其區別和優點如下：
1．從發展效率的角度看：
聯合查詢是需要多個單查詢邏輯組合才能完成的查詢工作，聯合查詢只需要一個SQL就可以完成查詢工作，即將業務邏輯轉化為SQL，由資料庫來處理，相對來說，開發效率會更高。
2．從查詢效率來看：
單個查詢具有更好的可重用性，因此比聯合查詢更有效。
當讀取或寫入資料庫時，資料庫使用鎖機制來限制其他連接對其進行操作。由於聯邦查詢比單個查詢慢得多，它們會增加鎖爭用，因此單個查詢更好。
3．從邏輯結構層面來看，分層原則
關聯表示業務規則／邏輯。如果經常使用關聯查詢，就會將大量的業務規則和邏輯放入資料庫中執行，這將大大增加CPU、內存、IO等資源的消耗。
4．從資源利用的角度來看
在大多數情況下，並不是所有相關查詢的結果都得到了有效的使用。例如，後台管理的列表界面會顯示分頁、關聯查詢的結果集，只使用當前頁面的數據，而資料庫需要消耗額外的資源才能得到整個結果集。
5．從架構的可伸縮性的角度來看
大量的相關查詢將導致集中式資料庫體系結構難以轉化為分布式體系結構，可擴展性優化也難以實現。關聯查詢方便快捷，開發效率更高。
不使用關系查詢在體系結構級別上有很多優勢，但是它需要大量的系統分析、設計和開發功能。一般在互聯網行業，如用戶數量最好重視這方面。
由於數據量小，兩個查詢的效率基本沒有差別，但在實際應用中，需要根據數據量、業務復雜度等進行綜合評價。
8. sql:查詢時快時慢
如果說是sql server 的話有這種情況，欄位越多，查詢可能越慢，並且如果你的欄位中有比如text，ntext之類的話會有這種情況；
還有，你的這種寫法可能也造成執行慢，SQL在執行時有這樣一個規則，不知道你是否了解，在執行時，SQL 後台會先執行編譯，找到一條最佳查詢路徑，也就是最快的查詢路徑，再真正執行查詢；這個編譯是需要時間的，如果條件復雜，或者由其它的變化而來的條件，會存在編譯的查找最佳路徑的時間問題；
資料庫的欄位越多，會有可能越慢，不管是否是空表，至於什麼原因，好像MICROSOFT沒有說法。
另外1=1這種恆等條件最好也不要加。
9. 一個sql查詢5000條很快,查詢到20000多條時特別慢
數量太大。sql是用於訪問和處理資料庫的標準的計算機語言。查詢5000條為正常水平，超過10000條系統就會難以成立造成卡頓變慢。
10. sql server資料庫中 表的查詢速率。
你的兩個表中的相同欄位都不是統一的數據格式，我很懷疑能不能查詢出來就是個問題更不要說查詢的速率慢了，首先你應該把其中的一個表中欄位強制轉換類型，然後再關聯
關聯後查詢速度沒有直接查詢速率快是很正常，因為它要訪問的是兩個表關聯後的虛擬表，也就是說查詢之前它需要把兩個表以相同欄位b將兩個表進行整合成一個虛擬表c保存再內存中，然後進行查詢，這樣下來速度當然會慢了。