當前位置:首頁 » 編程語言 » sql語句優化技巧
擴展閱讀
webinf下怎麼引入js 2023-08-31 21:54:13
堡壘機怎麼打開web 2023-08-31 21:54:11

sql語句優化技巧

發布時間: 2023-08-16 09:39:15

sql調優的幾種方式

你好,
SQL優化的一些方法
1.對查詢進行優化,應盡量避免全表掃描,首先應考慮在 where 及 order by 涉及的列上建立索引。
2.應盡量避免在 where 子句中對欄位進行 null 值判斷,否則將導致引擎放棄使用索引而進行全表掃描。
3.應盡量避免在 where 子句中使用!=或<>操作符,否則將引擎放棄使用索引而進行全表掃描。
4.應盡量避免在 where 子句中使用 or 來連接條件,否則將導致引擎放棄使用索引而進行全表掃描。
5.in 和 not in 也要慎用,否則會導致全表掃描,
6.下面的查詢也將導致全表掃描:
select id from t where name like '%abc%'
7.應盡量避免在 where 子句中對欄位進行表達式操作,這將導致引擎放棄使用索引而進行全表掃描。
8.應盡量避免在where子句中對欄位進行函數操作,這將導致引擎放棄使用索引而進行全表掃描。
9.不要在 where 子句中的「=」左邊進行函數、算術運算或其他表達式運算,否則系統將可能無法正確使用索引。
10.在使用索引欄位作為條件時,如果該索引是復合索引,那麼必須使用到該索引中的第一個欄位作為條件時才能保證系統使用該索引,否則該索引將不會被使用,並且應盡可能的讓欄位順序與索引順序相一致。

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

(2)sql語句優化技巧擴展閱讀:

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

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

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

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

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

❸ 如何進行SQL性能優化

這里分享下mysql優化的幾種方法。

1、首先在打開的軟體中,需要分別為每一個表創建 InnoDB FILE的文件。

❹ 如何優化SQL語句

一、問題的提出
在應用系統開發初期,由於開發資料庫數據比較少,對於查詢SQL語句,復雜視圖的的編寫等體會不出SQL語句各種寫法的性能優劣,但是如果將應用系統提交實際應用後,隨著資料庫中數據的增加,系統的響應速度就成為目前系統需要解決的最主要的問題之一。系統優化中一個很重要的方面就是SQL語句的優化。對於海量數據,劣質SQL語句和優質SQL語句之間的速度差別可以達到上百倍,可見對於一個系統不是簡單地能實現其功能就可,而是要寫出高質量的SQL語句,提高系統的可用性。
在多數情況下,Oracle使用索引來更快地遍歷表,優化器主要根據定義的索引來提高性能。但是,如果在SQL語句的where子句中寫的SQL代碼不合理,就會造成優化器刪去索引而使用全表掃描,一般就這種SQL語句就是所謂的劣質SQL語句。在編寫SQL語句時我們應清楚優化器根據何種原則來刪除索引,這有助於寫出高性能的SQL語句。
二、SQL語句編寫注意問題
下面就某些SQL語句的where子句編寫中需要注意的問題作詳細介紹。在這些where子句中,即使某些列存在索引,但是由於編寫了劣質的SQL,系統在運行該SQL語句時也不能使用該索引,而同樣使用全表掃描,這就造成了響應速度的極大降低。
1.
IS
NULL

IS
NOT
NULL
不能用null作索引,任何包含null值的列都將不會被包含在索引中。即使索引有多列這樣的情況下,只要這些列中有一列含有null,該列就會從索引中排除。也就是說如果某列存在空值,即使對該列建索引也不會提高性能。
任何在where子句中使用is
null或is
not
null的語句優化器是不允許使用索引的。
2.
聯接列
對於有聯接的列,即使最後的聯接值為一個靜態值,優化器是不會使用索引的。我們一起來看一個例子,假定有一個職工表(employee),對於一個職工的姓和名分成兩列存放(FIRST_NAME和LAST_NAME),現在要查詢一個叫比爾.柯林頓(Bill
Cliton)的職工。
下面是一個採用聯接查詢的SQL語句,
select
*
from
employss
where
first_name||''||last_name
='Beill
Cliton';
上面這條語句完全可以查詢出是否有Bill
Cliton這個員工,但是這里需要注意,系統優化器對基於last_name創建的索引沒有使用。
當採用下面這種SQL語句的編寫,Oracle系統就可以採用基於last_name創建的索引。
***
where
first_name
='Beill'
and
last_name
='Cliton';
.
帶通配符(%)的like語句
同樣以上面的例子來看這種情況。目前的需求是這樣的,要求在職工表中查詢名字中包含cliton的人。可以採用如下的查詢SQL語句:
select
*
from
employee
where
last_name
like
'%cliton%';
這里由於通配符(%)在搜尋詞首出現,所以Oracle系統不使用last_name的索引。在很多情況下可能無法避免這種情況,但是一定要心中有底,通配符如此使用會降低查詢速度。然而當通配符出現在字元串其他位置時,優化器就能利用索引。在下面的查詢中索引得到了使用:
select
*
from
employee
where
last_name
like
'c%';
4.
Order
by語句
ORDER
BY語句決定了Oracle如何將返回的查詢結果排序。Order
by語句對要排序的列沒有什麼特別的限制,也可以將函數加入列中(象聯接或者附加等)。任何在Order
by語句的非索引項或者有計算表達式都將降低查詢速度。
仔細檢查order
by語句以找出非索引項或者表達式,它們會降低性能。解決這個問題的辦法就是重寫order
by語句以使用索引,也可以為所使用的列建立另外一個索引,同時應絕對避免在order
by子句中使用表達式。
5.
NOT
我們在查詢時經常在where子句使用一些邏輯表達式,如大於、小於、等於以及不等於等等,也可以使用and(與)、or(或)以及not(非)。NOT可用來對任何邏輯運算符號取反。下面是一個NOT子句的例子:
...
where
not
(status
='VALID')
如果要使用NOT,則應在取反的短語前面加上括弧,並在短語前面加上NOT運算符。NOT運算符包含在另外一個邏輯運算符中,這就是不等於(<>)運算符。換句話說,即使不在查詢where子句中顯式地加入NOT詞,NOT仍在運算符中,見下例:
...
where
status
<>'INVALID';
對這個查詢,可以改寫為不使用NOT:
select
*
from
employee
where
salary<3000
or
salary>3000;
雖然這兩種查詢的結果一樣,但是第二種查詢方案會比第一種查詢方案更快些。第二種查詢允許Oracle對salary列使用索引,而第一種查詢則不能使用索引。
雖然這兩種查詢的結果一樣,但是第二種查詢方案會比第一種查詢方案更快些。第二種查詢允許Oracle對salary列使用索引,而第一種查詢則不能使用索引。

❺ SQL語句的幾種優化方法

1、盡可能建立索引,包括條件列,連接列,外鍵列等。

2、盡可能讓where中的列順序與復合索引的列順序一致。

3、盡可能不要select *,而只列出自己需要的欄位列表。

4、盡可能減少子查詢的層數。

5、盡可能在子查詢中進行數據篩選 。

❻ 【基於ORACLE資料庫的SQL語句優化分析】 資料庫查詢語句的優化

【摘要】隨著資料庫應用范圍及規模的不斷擴大,資料庫的性能問題逐漸顯現,優化資料庫有助於維持系統的穩定性以及運行的高效性。本文主要依據筆者在實際工作中的精坦敏拍英,對SQL語句優化的目的、SQL語句優化技術及原則進行全面分析和闡述。
【關鍵詞】ORACLE資料庫;SQL語句;優化
1前言
隨著現代化信息技術的迅猛發展,互聯網應用的日益普及,資料庫技術的影響力越來越大。作為信息系統管理的核心,資料庫的主要操作就是查詢,資料庫的應用效率在很大程度上是由查詢速度決定的,特別是對於規模較大的資料庫而言,查詢速度十分關鍵。查詢速度在SQL語句中佔有很大比重,所以,通過對查詢語句進行優化有助於促進應用系統性能及效率的進一步提升。
2SQL語句優化分析
2.1SQL語句優化的目的
對於一個資料庫而言,在確保設計無誤的前提下,要想避免出現性能問題必須確保其擁有合理的SQL語句拿喚結構。最簡單的資料庫尋找數據路徑是對SQL語句進行調整,ORACLE資料庫性能提升的主要途徑就是對SQL語句進行適當的調整。從本質上講,SQL語句優化就是確保所使用的語句可以被優化器識別,對索引進行有效利用以便控製表掃描的I/O次數,有效防止出現表搜索。用高性能的SQL語句替代低性能的SQL語句,確定最佳的數據查找路徑,盡可能使CPU時間與I/O時間保持平衡是進行優化的主要目的。在對SQL語句進行優化的過程中,以系統需求為依據確定最有可能實現性能提升的語句並進行優化。
2.2SQL語句優化技術及原則
當數據量積累到一定程度之後,對於資料庫全表SQL語句進行一次掃描,若查詢策略較好,一般只用幾秒鍾,但如果SQL語句性能較低,就需要用幾分鍾甚至更多時間。從這點不難看出,SQL語句性能對於查詢速度具有極大的影響,所以,對於應用系統而言,不僅能滿足功能的實現,還要保證SQL語句的質量。
(1)採取適宜的索引。為達到優化查詢的目的,一項重要工作就是確定相適應的索引,並嚴格依照原則加以使用,與此同時,為有效控制I/O競爭,不可以在同一個磁碟中同時建立索引和用戶表空間。
語句1:SELECT CUS_NO, CUS_NAME FROM CUSTOMER WHERE CUS_NO NOT IN
(SELECT CUS_NO FROM SERVICE);
語句2: SELECT CUS_NO, CUS_NAME FROM CUSTOMER WHERE NOT EXISTS
(SELECT * FROM SERVICE WHERE SERVICE.CUS_NO=CUSTOMER.CUS_NO);
上述兩個語句可以達到一致的查詢結果,對二者進行對比,當執行語句1時,由於ORACLE未利用CUSTOMER 表上CUS_NO索引,所以就會掃描整表,在執行語句2的過讓羨程中,ORACLE所掃描的只是CUSTOMER 表子查詢中的聯合查詢,並且使用了CUS_NO索引,因此,在執行效率方面明顯優於前者。
(2)避免在SELECT子句中出現「*」。ORACLE在進行解析時,需要按照一定順序對「*」進行轉換,該項轉換工作的進行需要對資料庫的數據字典進行查詢,勢必需要花費較多的時間,這樣就會導致較低的效率,所以,要避免在SELECT子句中出現「*」。
(3)如果必要可以利用COMMIT提交事務。ORACLE能夠自動提交DDL語句,而諸如DML等類型的語句的提交則是通過手動方式或者回滾事務實現的。在編寫應用程序的過程中,在操作諸如insert、delete以及update 等較為復雜的語境的時候,利用COMMIT提交事務可以講會話中持有的鎖加以釋放,將存在於緩存中的未經修改的數據塊進行清除,進而將系統資源予以釋放,促進系統性能的進一步提升,因此,如果有必要,可以利用COMMIT對相關事務進行提交。
(4)聯合查詢連接順序的確定。如果查詢操作涉及到多個表,基礎表應當是交叉表,所謂交叉表具體是指被其他表引用的表。連接執行效果在很大程度上受到FROM語句中表的順序的影響,對於FROM中所包含的表,ORACLE解析器進行處理的順序是由右至左,SQL語句中所選擇的基礎表會因優化器的不同而有所區別,在使用CBO的情況下,優化器會對SQL語句中各個表的物理大小以及索引狀態進行檢查,在此基礎上確定一個花費最小的執行路徑;在使用RBO的情況下,如果全部的連接條件均有索引與之相對應,那麼,FROM子句中位置最後面的表就是基礎表。
(5)IN用EXISTS取代。在對數個基礎表查詢過程中,一般需要進行表的連接。因為利用IN的子查詢過程中,ORACLE的掃描對象是全表,因此,出於提高查詢效率目的的考慮,應當將IN用EXISTS取代。
(6)在索引列中不使用計算。當通過對函數進行引用在WHERE子句中進行計算的時候,假如索引列只是函數的一部分,優化器就會針對全表進行掃描,而不會使用索引,所以,在索引列中不能使用函數。
3結語
綜上所述,隨著現代化信息技術的迅猛發展,互聯網應用的日益普及,資料庫技術的影響力越來越大。在信息量迅速激增的形勢下,資料庫優化調整成為當前所面臨的一大關鍵性問題,特別是對規模較大的資料庫而言,及時進行優化的意義更加倍重大。對於資料庫的運行性能而言,最主要的影響因素主要體現在以下幾點:資料庫系統架構的設計是否合理,資源配置是否科學以及SQL語句編寫效率等。筆者從事的是電信企業的運營分析工作,每天都要從資料庫取各種數據,可以說是離不開資料庫,所以在實踐中,我覺得嚴格遵守SQL語句優化原則及方法,並在實踐中及時總結經驗教訓,可以實現對系統響應時間的有效控制,促進運行效率的提升。
參考文獻
[1] 許開宇,胡文驊. 如何提高ORACLE資料庫應用程序的性能[J]. 計算機應用與軟體. 2002(10)
[2] 鄭耀,吳建嵐. 基於Oracle資料庫的語句優化策略[J]. 信息與電腦(理論版). 2011(07)
[3] 高攀,施蔚然. 基於Oracle資料庫的SQL語句優化[J]. 電腦編程技巧與維護. 2010(22)
[4] 鍾小權,葉猛. Oracle資料庫的SQL語句優化[J]. 計算機與現代化. 2011(03)
作者簡介:
王勇軍,男,(1981.1-),吉林通化人,就職於中國聯合網路通信有限公司長春市分公司,通信工程師,本科,研究方向:SQL使用
(作者單位:中國聯合網路通信有限公司長春市分公司)

❼ 這些SQL優化技巧握在手,面試可以橫著走……

一、SQL執行順序



二、基礎SQL優化


1、查詢SQL盡量不要使用select *,而是具體欄位


1)反例



2)正例



3)理由



2、避免在where子句中使用or來連接條件


查詢id為1或者薪水為3000的用戶:


1)反例



2)正例


使用union all:



分開兩條SQL寫:



3)理由



3、使用varchar代替char


1)反例



2)正例



3)理由



4、盡量使用數值替代字元串類型



5、查詢盡量避免返回大量數據


如果查詢返回數據量很大,就會造成查詢時間過長,網路傳輸時間過長。同時,大量數據返回也可能沒有實際意義。如返回上千條甚至更多,用戶也看不過來。

通常採用分頁,一頁習慣10/20/50/100條。


6、使用explain分析你SQL執行計劃


SQL很靈活,一個需求可以很多實現,那哪個最優呢?SQL提供了explain關鍵字,它可以分析你的SQL執行計劃,看它是否最佳。Explain主要看SQL是否使用了索引。



返回結果:



7、是否使用了索引及其掃描類型


type:



性能排行:


System > const > eq_ref > ref > range > index > ALL


possible_keys:



key:



8、創建name欄位的索引


提高查詢速度的最簡單最佳的方式。



9、優化like語句


模糊查詢,程序員最喜歡的就是使用like,但是like很可能讓你的索引失效。


1)反例



2)正例



3)理由


未使用索引,故意使用sex非索引欄位:




主鍵索引生效:




索引失效,type=ALL,全表掃描:




10、字元串怪現象


1)反例



2)正例



3)理由


為什麼第一條語句未加單引號就不走索引了呢?這是因為不加單引號時,是字元串跟數字的比較,它們類型不匹配,MySQL會做隱式的類型轉換,把它們轉換為數值類型再做比較。


11、索引不宜太多,一般5個以內



12、索引不適合建在有大量重復數據的欄位上


如性別欄位。因為SQL優化器是根據表中數據量來進行查詢優化的,如果索引列有大量重復數據,Mysql查詢優化器推算發現不走索引的成本更低,很可能就放棄索引了。


13、where限定查詢的數據


數據中假定就一個男的記錄。


1)反例



2)正例



3)理由



14、避免在索引列上使用內置函數


業務需求:查詢最近七天內新生兒(用學生表替代下)


給birthday欄位創建索引:



當前時間加7天:



1)反例



2)正例



3)理由







15、避免在where中對欄位進行表達式操作


1)反例



2)正例




3)理由






16、避免在where子句中使用!=或>操作符


應盡量避免在where子句中使用!=或>操作符,否則引擎將放棄使用索引而進行全表掃描。記住實現業務優先,實在沒辦法,就只能使用,並不是不能使用。如果不能使用,SQL也就無需支持了。


1)反例




2)理由




17、去重distinct過濾欄位要少





1)理由


18、where中使用默認值代替null


環境准備:




1)反例



2)正例



3)理由



三、高級SQL優化


1、批量插入性能提升


大量數據提交,上千,上萬,批量性能非常快,mysql獨有。


1)多條提交



2)批量提交



3)理由



2、批量刪除優化


避免同時修改或刪除過多數據,因為會造成cpu利用率過高,會造成鎖表操作,從而影響別人對資料庫的訪問。


1)反例




2)正例




3)理由



3、偽刪除設計


1)商品狀態(state)



2)理由



4、提高group by語句的效率


可以在執行到該語句前,把不需要的記錄過濾掉。


1)反例:先分組,再過濾



2)正例:先過濾,後分組



5、復合索引最左特性


創建復合索引,也就是多個欄位。



滿足復合索引的左側順序,哪怕只是部分,復合索引生效。



沒有出現左邊的欄位,則不滿足最左特性,索引失效。



復合索引全使用,按左側順序出現 name,salary,索引生效。



雖然違背了最左特性,但MYSQL執行SQL時會進行優化,底層進行顛倒優化。



1)理由



6、排序欄位創建索引


什麼樣的欄位才需要創建索引呢?原則就是where和order by中常出現的欄位就創建索引。



7、刪除冗餘和重復的索引




8、不要有超過5個以上的表連接



9、inner join 、left join、right join,優先使用inner join


三種連接如果結果相同,優先使用inner join,如果使用left join左邊表盡量小。



1)理由



10、in子查詢的優化


日常開發實現業務需求可以有兩種方式實現:



如需求:查詢所有部門的所有員工:



假設表A表示某企業的員工表,表B表示部門表,查詢所有部門的所有員工,很容易有以下程序實現,可以抽象成這樣的一個嵌套循環: