sql效率

『壹』 如何提高sql查詢的效率

你的題目太籠統，因為不同的寫法，不同的處理方式，不同的數據量，都會有不同的考慮，需要根據實際情況來提升，對於mssql，以下幾點可以參考
1、少用子查詢
2、少用or，當有or時，可以用union代替
3、查詢數據量太大，太慢，並且有子查詢時，可以考慮下臨時表處理
4、數據量大時，索引是提升效率的好手段
5、需要用到in的條件可以考慮用exists來取代
6、mssql的軟體有一個顯示計劃時間，可以幫助優化sql，就寫這么多吧，畢竟優化包含太多了，需要自己一點點的積累，並且不同場景不同處理

『貳』 sql執行效率

第二個效率高。
理由是sql查詢，會先走子查詢。數據量在一步步減少。
2個子查詢出來的數據會少很多。
第一個是全表關聯，所有的數據會有效。
建議：如果實際想知道哪一個快，可以用工具查看執行計劃，看看cost的使用量

『叄』 關於SQL語句的效率問題

一般說來，對於sex這樣的欄位，索引不索引都沒什麼效果，如果知道是boy，最好就別加這個條件。

對於你這樣的查詢，應該給name建議索引。

對於比較實用的資料庫管理系統（DBMS），系統會自動優化。對於比較垃圾的系統，很多時候沒辦法優化，比如有的資料庫只要存在OR就不走索引，那麼你上面的語句就沒有三次select來得快。

『肆』 SQL語句效率問題

對比查詢性能，不能只看語句，而是要看執行計劃。即使是相同的查詢語句，在不同的情況下也有可能生成不同的執行計劃。

之所以一個查詢性能高，是因為id欄位上有聚集索引。從查詢計劃來看，使用了合並連接(merge join)，合並連接是非常高效的連接。
而第二個查詢使用了max聚合，聚合運算本身效率比較低，而且因為聚合的使用，使得不能使用合並連接，而只能使用嵌套循環(nested loop)，所以效率低。

『伍』 sql裡面>1和>=2那個效率高點

>=2效率更高

原因是這樣的 >1 那資料庫每拿到一個數據都要和1進行比較，判斷是否小於1
但是>=2的話 資料庫只需要記得最小數字是2，其它數字都可以

這樣計算更少 所以也更快
PS：
>1和>=2效率是完全不一樣的。現在的sql優化器還不是非常智能。

『陸』 如何查看sql執行效率

在點擊某個按鈕,執行完後,再執行下面語句,就可以知道系統運行什麼Sql和多少次了,其主要慢語句是那些了;

--先清除sql server的緩存dbcc freeProcCache SELECT creation_time N'語句編譯時間' ,last_execution_time N'上次執行時間' ,total_physical_reads N'物理讀取總次數' ,total_logical_reads/execution_count N'每次邏輯讀次數' ,total_logical_reads N'邏輯讀取總次數' ,total_logical_writes N'邏輯寫入總次數' ,execution_count N'執行次數' ,total_worker_time/1000 N'所用的CPU總時間ms' ,total_elapsed_time/1000 N'總花費時間ms' ,(total_elapsed_time / execution_count)/1000 N'平均時間ms' ,SUBSTRING(st.text, (qs.statement_start_offset/2) + 1, ((CASE statement_end_offset WHEN -1 THEN DATALENGTH(st.text) ELSE qs.statement_end_offset END - qs.statement_start_offset)/2) + 1) N'執行語句'FROM sys.dm_exec_query_stats AS qsCROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) stwhere SUBSTRING(st.text, (qs.statement_start_offset/2) + 1, ((CASE statement_end_offset WHEN -1 THEN DATALENGTH(st.text) ELSE qs.statement_end_offset END - qs.statement_start_offset)/2) + 1) not like '%fetch%'ORDER BY total_elapsed_time / execution_count DESC;

『柒』 SQL效率問題

多次重復執行第二條語句，如果每次都慢，才能說明是第二條語句的固有問題。如果有時快有時慢，說明不是語句的固有問題，是跟資料庫負載以及buffer cache中的數據有關系。

如果確認是語句的固有問題，要准備定位15秒的時間究竟是花在哪裡，只有做trace這一種方法，其他方法都只是猜測。

做trace的方法網上可以搜到，之後對trace文件用tkprof處理，可以看到15秒都用在了哪裡，哪一步花了多少時間，這樣就可以准確定位出問題的地方。

如果lz不願意做trace，那麼根據經驗，我認為這個問題出在索引選擇（與第一條語句選擇的索引不同）的可能性第一，出在排序的可能性第二。

有不明白的，可以在明天pm我

補充：
什麼都不做就想知道問題具體是怎麼回事是做不到的
1、執行計劃貼出來看一下。
2、tkprof的結果貼出來看一下。
這兩者沒有，一切都是空談。

『捌』 sql語句的效率問題

給這個欄位加一個索引就行了

『玖』 對比sql語句效率

sql1是老式的聯表查詢，官方已經是不贊成現在還繼續使用這種查詢方式，而sql2是官方贊成的聯表查詢。現在基本上都是 sql2的查詢方式，所以在效率方面肯定是新技術勝過舊技術。

『拾』 如何提高sql語句的執行效率

1、使用ordered提示

Oracle必須花費大量的時間來剖析多表的合並，用以確定表合並的最佳順序。SQL表達式涉及七個乃至更多的表合並，那麼有時就會需要超過30分鍾的時間來剖析，Ordered這個提示(hint)和其他的提示一起使用能夠產生合適的合並順序。

2、使用ordered_predicates

ordered_predicates提示在查詢的WHERE子句里指定的，並被用來指定布爾判斷(Booleanpredicate)被評估的順序。在沒有ordered_predicates的情況下，Oracle會使用下面這些步驟來評估SQL判斷的順序：子查詢的評估先於外層WHERE子句里的Boolean條件。

所有沒有內置函數或者子查詢的布爾條件都按照其在WHERE子句里相反的順序進行評估，即最後一條判斷最先被評估。每個判斷都帶有內置函數的布爾判斷都依據其預計的評估值按遞增排列。

3、限製表格合並評估的數量

提高SQL剖析性能的最後一種方法是強製取代Oracle的一個參數，這個參數控制著在評估一個查詢的時候，基於消耗的優化器所評估的可能合並數量。

(10)sql效率擴展閱讀：

1、表設計的優化，數據行的長度不要超過8020位元組，如果超過這個長度的話在物理頁中這條數據會佔用兩行從而造成存儲碎片，降低查詢效率。

2、語句的查詢優化，保證在實現功能的基礎上，盡量減少對資料庫的訪問次數；

3、建立高效的索引創建索引一般有以下兩個目的：維護被索引列的唯一性和提供快速訪問表中數據的策略。

大型資料庫有兩種索引即簇索引和非簇索引，一個沒有簇索引的表是按堆結構存儲數據，所有的數據均添加在表的尾部，而建立了簇索引的表，其數據在物理上會按照簇索引鍵的順序存儲。個表只允許有一個簇索引。

4、強制查詢轉換，有時候oracle 的優化器未必能走正確的查詢路線，這個時候就需要添加一些hint 之類的來規定他的執行路線。當然了，這個未必是最好的處理方案。因為雖然現在走這個路線是對的，以為因為數據的變化到這這個HINT 變得不可取。