這裡蒐索程式師資訊,查找有用的技術資料
當前位置:首頁 » 編程語言 » sql語句執行效率
擴展閱讀
webinf下怎麼引入js 2023-08-31 21:54:13
堡壘機怎麼打開web 2023-08-31 21:54:11

sql語句執行效率

發布時間: 2022-04-12 03:28:49

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

調整不良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子句中使用表達式。

『貳』 如何查看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語句效率優化

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,以提高查詢效率。

數據更新的效率

1. 在一個事物中,對同一個表的多個insert語句應該集中在一起執行。

2. 在一個業務過程中,盡量的使insert,update,delete語句在業務結束前執行,以減少死鎖的可能性。

資料庫物理規劃的效率

為了避免I/O的沖突,我們在設計資料庫物理規劃時應該遵循幾條基本的原則(以ORACLE舉例):

?? table和index分離:table和index應該分別放在不同的tablespace中。

?? Rollback Segment的分離:Rollback Segment應該放在獨立的Tablespace中。

?? System Tablespace的分離:System Tablespace中不允許放置任何用戶的object。(mssql中primary filegroup中不允許放置任何用戶的object)

?? Temp Tablesace的分離:建立單獨的Temp Tablespace,並為每個user指定default Temp Tablespace

??避免碎片:但segment中出現大量的碎片時,會導致讀數據時需要訪問的block數量的增加。對經常發生DML操作的segemeng來說,碎片是不能完全避免的。所以,我們應該將經常做DML操作的表和很少發生變化的表分離在不同的Tablespace中。

當我們遵循了以上原則後,仍然發現有I/O沖突存在,我們可以用數據分離的方法來解決。

?? 連接Table的分離:在實際應用中經常做連接查詢的Table,可以將其分離在不同的Taclespace中,以減少I/O沖突。

?? 使用分區:對數據量很大的Table和Index使用分區,放在不同的Tablespace中。

在實際的物理存儲中,建議使用RAID。日誌文件應放在單獨的磁碟中。

『肆』 如何提高SQL語句的執行效率

需要提高效率,可以從以下考慮:
第一,建立搜索條件對應的索引
第二,盡量不要使用 select * ,應該改成 select 列1,列2,...
第三,升級SQL版本,SQL2008比SQL2000的速度提高是很多的
第四,如果表有大容量的欄位,如 圖片,文檔,應該考慮用FTP來做,不是把數據放在資料庫

『伍』 mysql查看sql執行效率

Explain命令在解決資料庫性能上是第一推薦使用命令,大部分的性能問題可以通過此命令來簡單的解決,Explain可以用來查看 SQL 語句的執行效 果,可以幫助選擇更好的索引和優化查詢語句,寫出更好的優化語句。
Explain語法:explain select … from … [where ...]
例如:explain select * from 表名;

『陸』 以下哪種方法執行SQL語句最有效率

優化sql語句執行效率的方法:
1)盡量選擇較小的列
2)將where中用的比較頻繁的欄位建立索引
3)select子句中避免使用『*』
4)避免在索引列上使用計算、not in 和<>等操作
5)當只需要一行數據的時候使用limit 1
6)保證單表數據不超過200W,適時分割表。
針對查詢較慢的語句,可以使用explain 來分析該語句具體的執行情況。

『柒』 sql語言的執行效率

使用explain命令,寫在執行的sql前面,即可查看執行過程,看看索引使用情況

『捌』 如何提高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的一個參數,這個參數控制著在評估一個查詢的時候,基於消耗的優化器所評估的可能合並數量。

(8)sql語句執行效率擴展閱讀:

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

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

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

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

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

『玖』 sql查詢語句效率提問 對小弟來說非常高深!!!

答案是
:
效率是不同的
From
後面的表:效率最高(記錄少,有索引)的表在最後,效率低的表在最左(記錄多,無索引)
From
一般都是逆序,比如你的sql語言,資料庫會先處理你的table_2
Where
後面的條件:從左到右的順序,將效率高的比較放在前面(可以過濾更多的數據,從而減少後面條件的處理)
Where
條件一般都是順序。表連接條件執行效率是比較高的,應該放在前面
所以你的兩句sql語言,前者的效率更高。
並且可以改變table_1和Table2的位置讓你的效率更高

『拾』 SQL語句 怎樣提高select語句的執行效率

需要提高效率,可以從以下考慮:
第一,建立搜索條件對應的索引
第二,盡量不要使用
select
*
,應該改成
select
列1,列2,...
第三,升級SQL版本,SQL2008比SQL2000的速度提高是很多的
第四,如果表有大容量的欄位,如
圖片,文檔,應該考慮用FTP來做,不是把數據放在資料庫