SQL優化

時間 2019-12-08

標籤 sql 優化欄目 SQL 简体版

原文原文鏈接

1.SQL優化：https://tech.meituan.com/2014/06/30/mysql-index.html html

a.索引的目的在於提升查詢效率，能夠類比字典目錄，經過不斷的縮小想要得到數據的範圍來篩選出最終想要的結果，同時把隨機的事件變成順序的事件。
mysql

若是要查找數據項29，那麼首先會把磁盤塊1由磁盤加載到內存，此時發生一次IO，在內存中用二分查找肯定29在17和35之間，鎖定磁盤塊1的P2指針，內存時間由於很是短（相比磁盤的IO）能夠忽略不計，經過磁盤塊1的P2指針的磁盤地址把磁盤塊3由磁盤加載到內存，發生第二次IO，29在26和30之間，鎖定磁盤塊3的P2指針，經過指針加載磁盤塊8到內存，發生第三次IO，同時內存中作二分查找找到29，結束查詢，總計三次IO。

IO次數取決於b+數的高度h，假設當前數據表的數據爲N，每一個磁盤塊的數據項的數量是m，則有h=㏒(m+1)N，當數據量N必定的狀況下，m越大，h越小；而m = 磁盤塊的大小 / 數據項的大小，磁盤塊的大小也就是一個數據頁的大小，是固定的，若是數據項佔的空間越小，數據項的數量越多，樹的高度越低。所以索引字段要儘可能的小

當b+樹的數據項是複合的數據結構，好比(name,age,sex)的時候，b+數是按照從左到右的順序來創建搜索樹的，好比當(張三,20,F)這樣的數據來檢索的時候，b+樹會優先比較name來肯定下一步的所搜方向，若是name相同再依次比較age和sex，最後獲得檢索的數據；但當(20,F)這樣的沒有name的數據來的時候，b+樹就不知道下一步該查哪一個節點，由於創建搜索樹的時候name就是第一個比較因子，必需要先根據name來搜索才能知道下一步去哪裏查詢。好比當(張三,F)這樣的數據來檢索時，b+樹能夠用name來指定搜索方向，但下一個字段age的缺失，因此只能把名字等於張三的數據都找到，而後再匹配性別是F的數據了，這個是很是重要的性質，即索引的最左匹配特性。

最左前綴匹配原則，很是重要的原則，mysql會一直向右匹配直到遇到範圍查詢(>、<、between、like)就中止匹配，好比a = 1 and b = 2 and c > 3 and d = 4 若是創建(a,b,c,d)順序的索引，d是用不到索引的，若是創建(a,b,d,c)的索引則均可以用到，a,b,d的順序能夠任意調整。 2.=和in能夠亂序，好比a = 1 and b = 2 and c = 3 創建(a,b,c)索引能夠任意順序，mysql的查詢優化器會幫你優化成索引能夠識別的形式。 3.儘可能選擇區分度高的列做爲索引,區分度的公式是count(distinct col)/count(*)，表示字段不重複的比例，比例越大咱們掃描的記錄數越少，惟一鍵的區分度是1，而一些狀態、性別字段可能在大數據面前區分度就是0sql

索引列不能參與計算，保持列「乾淨」，好比from_unixtime(create_time) = ’2014-05-29’就不能使用到索引，緣由很簡單，b+樹中存的都是數據表中的字段值，但進行檢索時，須要把全部元素都應用函數才能比較，顯然成本太大。因此語句應該寫成create_time = unix_timestamp(’2014-05-29’)。數據庫

儘可能的擴展索引，不要新建索引。好比表中已經有a的索引，如今要加(a,b)的索引，那麼只須要修改原來的索引便可。服務器

explain使用時：注意rows

慢查詢優化基本步驟

0.先運行看看是否真的很慢，注意設置SQL_NO_CACHE 1.where條件單表查，鎖定最小返回記錄表。這句話的意思是把查詢語句的where都應用到表中返回的記錄數最小的表開始查起，單表每一個字段分別查詢，看哪一個字段的區分度最高 2.explain查看執行計劃，是否與1預期一致（從鎖定記錄較少的表開始查詢） 3.order by limit 形式的sql語句讓排序的表優先查 4.瞭解業務方使用場景 5.加索引時參照建索引的幾大原則 6.觀察結果，不符合預期繼續從0分析

1.對查詢進行優化，要儘可能避免全表掃描，首先應考慮在 where 及 order by 涉及的列上創建索引。數據結構

2.應儘可能避免在 where 子句中對字段進行 null 值判斷，不然將致使引擎放棄使用索引而進行全表掃描，如：併發

select id from t where num is null

最好不要給數據庫留NULL，儘量的使用 NOT NULL填充數據庫.oracle

備註、描述、評論之類的能夠設置爲 NULL，其餘的，最好不要使用NULL。函數

不要覺得 NULL 不須要空間，好比：char(100) 型，在字段創建時，空間就固定了，無論是否插入值（NULL也包含在內），都是佔用 100個字符的空間的，若是是varchar這樣的變長字段， null 不佔用空間。sqlserver

能夠在num上設置默認值0，確保表中num列沒有null值，而後這樣查詢：

select id from t where num = 0

3.應儘可能避免在 where 子句中使用 != 或 <> 操做符，不然將引擎放棄使用索引而進行全表掃描。

4.應儘可能避免在 where 子句中使用 or 來鏈接條件，若是一個字段有索引，一個字段沒有索引，將致使引擎放棄使用索引而進行全表掃描，如：

select id from t where num=10 or Name = 'admin'

能夠這樣查詢：

select id from t where num = 10
union all
select id from t where Name = 'admin'

5.in 和 not in 也要慎用，不然會致使全表掃描，如：

select id from t where num in(1,2,3)

對於連續的數值，能用 between 就不要用 in 了：

select id from t where num between 1 and 3

不少時候用 exists 代替 in 是一個好的選擇：

select num from a where num in(select num from b)

用下面的語句替換：

select num from a where exists(select 1 from b where num=a.num)

6.下面的查詢也將致使全表掃描：

select id from t where name like ‘%abc%’

若要提升效率，能夠考慮全文檢索。

7.若是在 where 子句中使用參數，也會致使全表掃描。由於SQL只有在運行時纔會解析局部變量，但優化程序不能將訪問計劃的選擇推遲到運行時；它必須在編譯時進行選擇。然而，若是在編譯時創建訪問計劃，變量的值仍是未知的，於是沒法做爲索引選擇的輸入項。以下面語句將進行全表掃描：

select id from t where num = @num

能夠改成強制查詢使用索引：

select id from t with(index(索引名)) where num = @num

.應儘可能避免在 where 子句中對字段進行表達式操做，這將致使引擎放棄使用索引而進行全表掃描。如：

select id from t where num/2 = 100

應改成:

select id from t where num = 100*2

9.應儘可能避免在where子句中對字段進行函數操做，這將致使引擎放棄使用索引而進行全表掃描。如：

select id from t where substring(name,1,3) = ’abc’ -–name以abc開頭的id select id from t where datediff(day,createdate,’2005-11-30′) = 0 -–‘2005-11-30’    --生成的id

應改成:

select id from t where name like 'abc%'
select id from t where createdate >= '2005-11-30' and createdate < '2005-12-1'

10.不要在 where 子句中的「=」左邊進行函數、算術運算或其餘表達式運算，不然系統將可能沒法正確使用索引。

11.在使用索引字段做爲條件時，若是該索引是複合索引，那麼必須使用到該索引中的第一個字段做爲條件時才能保證系統使用該索引，不然該索引將不會被使用，而且應儘量的讓字段順序與索引順序相一致。

12.不要寫一些沒有意義的查詢，如須要生成一個空表結構：

select col1,col2 into #t from t where 1=0

這類代碼不會返回任何結果集，可是會消耗系統資源的，應改爲這樣：
create table #t(…)

13.Update 語句，若是隻更改一、2個字段，不要Update所有字段，不然頻繁調用會引發明顯的性能消耗，同時帶來大量日誌。

14.對於多張大數據量（這裏幾百條就算大了）的表JOIN，要先分頁再JOIN，不然邏輯讀會很高，性能不好。

15.select count(*) from table；這樣不帶任何條件的count會引發全表掃描，而且沒有任何業務意義，是必定要杜絕的。

16.索引並非越多越好，索引當然能夠提升相應的 select 的效率，但同時也下降了 insert 及 update 的效率，由於 insert 或 update 時有可能會重建索引，因此怎樣建索引須要慎重考慮，視具體狀況而定。一個表的索引數最好不要超過6個，若太多則應考慮一些不常使用到的列上建的索引是否有必要。

17.應儘量的避免更新 clustered 索引數據列，由於 clustered 索引數據列的順序就是表記錄的物理存儲順序，一旦該列值改變將致使整個表記錄的順序的調整，會耗費至關大的資源。若應用系統須要頻繁更新 clustered 索引數據列，那麼須要考慮是否應將該索引建爲 clustered 索引。

18.儘可能使用數字型字段，若只含數值信息的字段儘可能不要設計爲字符型，這會下降查詢和鏈接的性能，並會增長存儲開銷。這是由於引擎在處理查詢和連接時會逐個比較字符串中每個字符，而對於數字型而言只須要比較一次就夠了。

19.儘量的使用 varchar/nvarchar 代替 char/nchar ，由於首先變長字段存儲空間小，能夠節省存儲空間，其次對於查詢來講，在一個相對較小的字段內搜索效率顯然要高些。

20.任何地方都不要使用 select * from t ，用具體的字段列表代替「*」，不要返回用不到的任何字段。

21.儘可能使用表變量來代替臨時表。若是表變量包含大量數據，請注意索引很是有限（只有主鍵索引）。

22. 避免頻繁建立和刪除臨時表，以減小系統表資源的消耗。臨時表並非不可以使用，適當地使用它們可使某些例程更有效，例如，當須要重複引用大型表或經常使用表中的某個數據集時。可是，對於一次性事件，最好使用導出表。

23.在新建臨時表時，若是一次性插入數據量很大，那麼可使用 select into 代替 create table，避免形成大量 log ，以提升速度；若是數據量不大，爲了緩和系統表的資源，應先create table，而後insert。

24.若是使用到了臨時表，在存儲過程的最後務必將全部的臨時表顯式刪除，先 truncate table ，而後 drop table ，這樣能夠避免系統表的較長時間鎖定。

25.儘可能避免使用遊標，由於遊標的效率較差，若是遊標操做的數據超過1萬行，那麼就應該考慮改寫。

26.使用基於遊標的方法或臨時表方法以前，應先尋找基於集的解決方案來解決問題，基於集的方法一般更有效。

27.與臨時表同樣，遊標並非不可以使用。對小型數據集使用 FAST_FORWARD 遊標一般要優於其餘逐行處理方法，尤爲是在必須引用幾個表才能得到所需的數據時。在結果集中包括「合計」的例程一般要比使用遊標執行的速度快。若是開發時間容許，基於遊標的方法和基於集的方法均可以嘗試一下，看哪種方法的效果更好。

28.在全部的存儲過程和觸發器的開始處設置 SET NOCOUNT ON ，在結束時設置 SET NOCOUNT OFF 。無需在執行存儲過程和觸發器的每一個語句後向客戶端發送 DONE_IN_PROC 消息。

29.儘可能避免大事務操做，提升系統併發能力。

30.儘可能避免向客戶端返回大數據量，若數據量過大，應該考慮相應需求是否合理。

實際案例分析：

拆分大的 DELETE 或INSERT 語句，批量提交SQL語句。
若是你須要在一個在線的網站上去執行一個大的 DELETE 或 INSERT 查詢，你須要很是當心，要避免你的操做讓你的整個網站中止相應。由於這兩個操做是會鎖表的，表一鎖住了，別的操做都進不來了。
　　Apache 會有不少的子進程或線程。因此，其工做起來至關有效率，而咱們的服務器也不但願有太多的子進程，線程和數據庫連接，這是極大的佔服務器資源的事情，尤爲是內存。
　　若是你把你的表鎖上一段時間，好比30秒鐘，那麼對於一個有很高訪問量的站點來講，這30秒所積累的訪問進程/線程，數據庫連接，打開的文件數，可能不只僅會讓你的WEB服務崩潰，還可能會讓你的整臺服務器立刻掛了。
　　因此，若是你有一個大的處理，你必定把其拆分，使用 LIMIT oracle(rownum),sqlserver(top)條件是一個好的方法。下面是一個mysql示例：

int deleteCount = 0;
do {
    deleteCount = jdbcTemplate.update("delete from logs where log_date <= ’2012-11-01’ limit 1000");
    TimeUnit.SECONDS.sleep(10);//每次暫停一段時間，釋放表讓其餘進程/線程訪問。
} while (deleteCount > 0);

來源： https://wiki.lagou.com/pages/viewpage.action?pageId=12027035

bp_goods_attach索引以下：

使用or出現索引不命中

修改爲union all能正常命中索引(key)

各屬性含義：
id: 查詢的序列號
select_type: 查詢的類型，主要是區別普通查詢和聯合查詢、子查詢之類的複雜查詢

SIMPLE：查詢中不包含子查詢或者UNION
查詢中若包含任何複雜的子部分，最外層查詢則被標記爲：PRIMARY
在SELECT或WHERE列表中包含了子查詢，該子查詢被標記爲：SUBQUERY

    table: 輸出的行所引用的表
    type: 訪問類型  從左至右，性能由差到好

ALL: 掃描全表
index: 掃描所有索引樹
range: 掃描部分索引，索引範圍掃描，對索引的掃描開始於某一點，返回匹配值域的行，常見於between、<、>等的查詢
ref: 使用非惟一索引或非惟一索引前綴進行的查找
（eq_ref和const的區別：）
eq_ref：惟一性索引掃描，對於每一個索引鍵，表中只有一條記錄與之匹配。常見於主鍵或惟一索引掃描
const, system: 單表中最多有一個匹配行，查詢起來很是迅速，例如根據主鍵或惟一索引查詢。system是const類型的特例，當查詢的表只有一行的狀況下，使用system。
NULL: 不用訪問表或者索引，直接就能獲得結果，如select 1 from test where 1

possible_keys: 表示查詢時可能使用的索引。若是是空的，沒有相關的索引。這時要提升性能，可經過檢驗WHERE子句，看是否引用某些字段，或者檢查字段不是適合索引

key: 顯示MySQL實際決定使用的索引。若是沒有索引被選擇，是NULL

key_len: 使用到索引字段的長度

注：key_len顯示的值爲索引字段的最大可能長度，並不是實際使用長度，即key_len是根據表定義計算而得，不是經過表內檢索出的。

ref: 顯示哪一個字段或常數與key一塊兒被使用

rows: 這個數表示mysql要遍歷多少數據才能找到，表示MySQL根據表統計信息及索引選用狀況，估算的找到所需的記錄所須要讀取的行數，在innodb上多是不許確的

Extra: 執行狀況的說明和描述。包含不適合在其餘列中顯示但十分重要的額外信息。