SQL存儲過程放在SQL資料庫中，因此在程序中調用的時候不必自己拼接sql語句。資料庫會對存儲過程進行預編譯，因此速度快。3，在網路上不必傳輸冗長的SQL語句，而是直接調用存儲過程的名字，因此可以加快速度當然，在一些外包軟體開發中，是不允許使用存儲過程的。因為對方不可以把資料庫暴露給你，此時你只能使用SQL語句。不過國內的一些小型企業使用SQL存儲過程還是很流行的。因為程序代碼里不包含SQL語句，因此會資料庫會相對安全一些。
Ⅱ 用ETL組件實現和sql相比哪個效率高
樓主好，我現在正在做BI相關的東西。如果ETL和SQL來說，肯定是SQL效率高的多。但是雙方各有優勢，先說ETL，ETL主要面向的是建立數據倉庫來使用的。ETL更偏向數據清洗，多數據源數據整合，獲取增量，轉換載入到數據倉庫所使用的工具。比如我有兩個數據源，一個是資料庫的表，另外一個是excel數據，而我需要合並這兩個數據，通常這種東西在SQL語句中比較難實現。但是ETL卻有很多現成的組件和驅動，幾個組件就搞定了。還有比如跨伺服器，並且伺服器之間不能建立連接的數據源，比如我們公司系統分為一期和二期，存放的資料庫是不同的，數據結構也不相同，資料庫之間也不能建立連接，這種情況下，ETL就顯得尤為重要和突出。通過固定的抽取，轉換，載入到數據倉庫中，即可很容易實現。
那麼SQL呢？SQL事實上只是固定的腳本語言，但是執行效率高，速度快。不過靈活性不高，很難跨伺服器整合數據。所以SQL更適合在固定資料庫中執行大范圍的查詢和數據更改，由於腳本語言可以隨便編寫，所以在固定資料庫中能夠實現的功能就相當強大，不像ETL中功能只能受組件限制，組件有什麼功能，才能實現什麼功能。
所以具體我們在什麼時候使用ETL和SQL就很明顯了，當我們需要多數據源整合建立數據倉庫，並進行數據分析的時候，我們使用ETL。如果是固定單一資料庫的數據層次處理，我們就使用SQL。當然，ETL也是離不開SQL的。
Ⅲ java程序中寫sql語句和存儲過程 哪個效率高些
1、存儲過程是已經編譯過的，在執行時效率高
2、在程序中的SQL語句，每次都要經過資料庫伺服器的編譯、校驗、索引選擇、緩存選擇等等步驟。相對存儲過程是慢的
3、當然也有些事情是必須要在程序中處理，例如：字元串的處理，各種情況的判斷等，這個不能一概而論，需要具體場景具體分析，然後選擇最優的方法來試用。
Ⅳ 項目中優化sql語句執行效率的方法是什麼
1. SQL優化的原則是：將一次操作需要讀取的BLOCK數減到最低,即在最短的時間達到最大的數據吞吐量。
調整不良SQL通常可以從以下幾點切入：
? 檢查不良的SQL，考慮其寫法是否還有可優化內容
? 檢查子查詢 考慮SQL子查詢是否可以用簡單連接的方式進行重新書寫
? 檢查優化索引的使用
? 考慮資料庫的優化器
2. 避免出現SELECT * FROM table 語句，要明確查出的欄位。
3. 在一個SQL語句中，如果一個where條件過濾的資料庫記錄越多，定位越准確，則該where條件越應該前移。
4. 查詢時盡可能使用索引覆蓋。即對SELECT的欄位建立復合索引，這樣查詢時只進行索引掃描，不讀取數據塊。
5. 在判斷有無符合條件的記錄時建議不要用SELECT COUNT （*）和select top 1 語句。
6. 使用內層限定原則，在拼寫SQL語句時，將查詢條件分解、分類，並盡量在SQL語句的最里層進行限定，以減少數據的處理量。
7. 應絕對避免在order by子句中使用表達式。
8. 如果需要從關聯表讀數據，關聯的表一般不要超過7個。
9. 小心使用 IN 和 OR，需要注意In集合中的數據量。建議集合中的數據不超過200個。
10. <> 用 < 、 > 代替，>用>=代替，<用<=代替，這樣可以有效的利用索引。
11. 在查詢時盡量減少對多餘數據的讀取包括多餘的列與多餘的行。
12. 對於復合索引要注意，例如在建立復合索引時列的順序是F1，F2，F3，則在where或order by子句中這些欄位出現的順序要與建立索引時的欄位順序一致，且必須包含第一列。只能是F1或F1，F2或F1，F2，F3。否則不會用到該索引。
13. 多表關聯查詢時，寫法必須遵循以下原則，這樣做有利於建立索引，提高查詢效率。格式如下select sum（table1.je） from table1 table1, table2 table2, table3 table3 where (table1的等值條件（=）) and (table1的非等值條件) and (table2與table1的關聯條件) and (table2的等值條件) and (table2的非等值條件) and (table3與table2的關聯條件) and (table3的等值條件) and (table3的非等值條件)。
注:關於多表查詢時from 後面表的出現順序對效率的影響還有待研究。
14. 子查詢問題。對於能用連接方式或者視圖方式實現的功能，不要用子查詢。例如：select name from customer where customer_id in ( select customer_id from order where money>1000)。應該用如下語句代替：select name from customer inner join order on customer.customer_id=order.customer_id where order.money>100。
15. 在WHERE 子句中，避免對列的四則運算，特別是where 條件的左邊，嚴禁使用運算與函數對列進行處理。比如有些地方 substring 可以用like代替。
16. 如果在語句中有not in（in）操作，應考慮用not exists（exists）來重寫,最好的辦法是使用外連接實現。
17. 對一個業務過程的處理，應該使事物的開始與結束之間的時間間隔越短越好，原則上做到資料庫的讀操作在前面完成，資料庫寫操作在後面完成，避免交叉。
18. 請小心不要對過多的列使用列函數和order by,group by等，謹慎使用disti軟體開發t。
19. 用union all 代替 union，資料庫執行union操作，首先先分別執行union兩端的查詢，將其放在臨時表中，然後在對其進行排序，過濾重復的記錄。
當已知的業務邏輯決定query A和query B中不會有重復記錄時，應該用union all代替union，以提高查詢效率。
Ⅳ SQL查詢和實體查詢那個查詢效率高
你說的實體查詢是什麼意思？ORM那些東西嗎？
如果是，那麼還是sql的效率高，很簡單，因為實體最終還是要轉化為sql去查詢。使用orm的意義，不在於提高你的執行效率，而在於提高你的開發效率，是要把非面向對象的sql操作，轉化為面向對象的實體操作。
Ⅵ 為什麼存儲過程比sql語句效率高
1 存儲過程允許標准組件式編程
存儲過程在被創建以後可以在程序中被多次調用而不必重新編寫該存儲過程的sql
語句而且資料庫專業人員可隨時對存儲過程進行修改但對應用程序源代碼毫無影響因
為應用程序源代碼只包含存儲過程的調用語句從而極大地提高了程序的可移植性
2 存儲過程能夠實現較快的執行速度
如果某一操作包含大量的transaction-sql 代碼或分別被多次執行那麼存儲過程要
比批處理的執行速度快很多因為存儲過程是預編譯的在首次運行一個存儲過程時查詢優化器對其進行分析優化並給出最終被存在系統表中的執行計劃而批處理的transaction-
sql 語句在每次運行時都要進行編譯和優化因此速度相對要慢一些
3 存儲過程能夠減少網路流量
對於同一個針對數據資料庫對象的操作如查詢修改如果這一操作所涉及到的
transaction-sql 語句被組織成一存儲過程那麼當在客戶計算機上調用該存儲過程時
網路中傳送的只是該調用語句否則將是多條sql 語句從而大大增加了網路流量降
低網路負載
4 存儲過程可被作為一種安全機制來充分利用
系統管理員通過對執行某一存儲過程的許可權進行限制從而能夠實現對相應的數據訪
問許可權的限制避免非授權用戶對數據的訪問保證數據的安全
Ⅶ LINQ比一般的SQL語句效率更高嗎
Linq是一個范圍比較大的概念，它其中不單單只有linq to sql，還有相應的linq to xml等等。所以拿linq 與SQL語句相比，沒有可比性的。
但如果拿linq to sql相比的話，與SQL還是有很大的可比性的。一般情況下，你必須要明白你所指的效率是哪一方面？是資料庫執行效率？還是整體成品軟體運行效率？還是開發效率？
開發效率上linq to sql顯然要比SQL的效率要高很多，我們使用linq to sql 可以很容易實現編程，其中的代碼量也大大減少。所以如果從開發方面linq to sql的效率是毫無疑問要高於直接的SQL與資料庫連接。
如果從編方譯考慮，這個一般情況下，linq to sql是引入的新的技術，效率肯定是不如SQL的。好在這個編譯的部分不需要開發人員或是任何用戶的參與，所以即是效率差一點，對軟體來說沒有任何的影響。
最後一部分你可以比較感興趣，誰對資料庫的連接更快，執行效率更好？答案是linq to sql而不是直接的語句。一般我們使用直接的語句要求的是即是的執行，但事實上很多時間我們根本不需要那麼多，linq to sql其實說明了就是會自動生成與表結構同樣的一些對象。而這些對象在聯系資料庫時也是直接編譯好的語句，直接聯系時，兩者效率是相同的。
但是，如果我們對數據進行處理時，你就會發現，linq to sql的效率為什麼會更高了！因為他在讀取時不但會讀取當前表來填充生成的對象，同時還是延時讀其相關表，為你使用有關系的表提供了極大的方便。那麼你的相關表的讀取效率要快了！
但不管怎麼樣，他們都是在站立在了ado.net的基礎之上的，只不過有些自動生成了，根本不需要你再去做而已。唯一效果比較差的是，linq to sql讀出的數據在系統中被轉化了，同時它效率雖然變差一些，但是卻帶來了另一個好處，就是我們常說的SQL注入問題不再出現，你所輸入的任何東西都會變成了字元串了。
其實ADO.net的方案中我們使用了datareader方案的效高是比較高的，但是對於更新卻是極差的。而使用數據適配器的方案效率較底一些，更對於數據的更新是相當好的，而對於linq to sql其實它是使用數據緩存方案，也就是說linq to sql其實將資料庫中的數據緩存到了對象中，如果對象發生了更改，有必須過行返饋時，它是可以進行反饋的，而是這種反饋是可控制的，事務性的。從各方面給我們帶來了好處。
我們可以在更新了很多內容之後再去提交更改，那麼這種效率論從理解上還是效率上都優化你的原來的語句的！所以linq to sql並非在性能上的降低，而是一種提高。
嚴格說來，linq to sql並不是節省了代碼，相反它增加了很多代碼，便幸運的是，這些代碼都是由linq to sql框架自動生成的。若是換作人工，容易出錯的。但在使用時，由於框架完成了大部分的代碼，我們再使用linq to sql加上lambad表達式或查詢表達式，我們的代碼就變得極少且極簡潔了！而如果使用lambad表達式或查詢表達式時，它的效率顯然不如直接SQL來的直接。讀取效率會變得差一些的！
這是因為lambda表達式或查詢表達式是一個動態編譯的效果，而不是直接編譯好的，他要對語句進行編譯與優化以何證效率，但性能上因為多了一重處理，效率沒有SQL來的直接。但一般情況下，使用linq to sql配合查詢表達式或lambad表達式時，效率雖然稍差，但是帶來的卻是代碼的簡潔與易理解性，如果不配合查詢表達式與lambad表達式，linq to sql的優劣還不利用體現。所以關非linq to sql的效率差，而是我們使用了查詢表達式的動態編譯導致了效率較差。就linq to sql本身上來就，效率並不差的！
Ⅷ 關於sql優化是什麼意思
就是你的sql查詢效率太低，需要優化。使其查詢效率高，處理時間段。
比如，修改查詢條件。select * 和 select 欄位1，欄位2，處理時間不一致的。
再比如， where條件， where to_char(date,'yyyy/mm/dd') = '2018/03/19' 和 where date = to_date('2018/03/19' ,'yyyy/mm/dd')
數據多，會有很大的差別。上100w，1000w，億的數據
Ⅸ 同樣的SQL語句在SQL2000中的執行效率反而大大高於SQL2008，不解！
呵呵,要看在什麼情況下做的.如果你本來就是sql 2000的語句,以前在sql 2000上運行過,那麼很正常的.sql server 對於陌生語句的執行是要花很多時間,可是如果你重復運行看看.那個時間叫一個短啊...
另外也要看索引是什麼樣子的?如果sql 2000上存在索引,而2008上沒有索引.那麼你得到的結論很正常的.
最後這種問題其實沒有必要問,mssql 開發組的人都不是sb,他們不會把sql 2008做的比2000還差.還有就是2000和20008完全就不是同一個核心.你;連2005都沒用,就直接跳躍到2008,太牛了.
Ⅹ sql語句聯合查詢 與 視圖想比較的話，那個效率快，為什麼。
sql效率比較快，存儲過程的好處是不僅快且更安全，但移植性差。視圖可以封裝查詢的復雜性，就像面向對象里類的概念一樣。