一、SQL在數據庫中的執行過程

二、執行計劃

1. ACID

原子性：一個事務（transaction）中的所有操作，要麽全部完成，要麽全部不完成，不會結束在中間某個環節。事務在執行過程中發生錯誤，會被恢復（Rollback）到事務開始前的狀態，就像這個事務從來沒有執行過一樣。
一致性：在事務開始之前和事務結束以後，數據庫的完整性沒有被破壞。這表示寫入的資料必須完全符合所有的預設規則，這包含資料的精確度、串聯性以及後續數據庫可以自發性地完成預定的工作。
隔離性：數據庫允許多個並發事務同時對其數據進行讀寫和修改的能力，隔離性可以防止多個事務並發執行時由於交叉執行而導致數據的不一致。事務隔離分為不同級別，包括讀未提交（Read uncommitted）、讀提交（read committed）、可重復讀（repeatable read）和串行化（Serializable）。
持久性：事務處理結束後，對數據的修改就是永久的，即便系統故障也不會丟失。

2. 鎖

2.1.按照對數據操作的類型分
讀鎖：也稱為共享鎖，針對同一資源，多個讀操作是可以並行進行的，並且互不影響。
寫鎖：也稱排它鎖。 當前線程寫數據的時候，會阻斷其他線程來讀數據和寫數據
2.2 按照 粒度來分
表鎖：就是鎖整個表（myisam）
行鎖：就是鎖單獨某個表中的某一行(innodb)
葉鎖：他是鑒於表鎖和行數之間的一種粒度

3. 執行計劃Explain

EXPLAIN SELECT * from tbl_notices

執行計劃的各列說明：

1.Id，SQL執行的順利的標識,SQL從大到小的執行.
2. select_type，就是查詢的類型,可以有以下幾種：

　　2.1、SIMPLE，簡單查詢
　　2.2、PRIMARY，主查詢（多個表關聯時）
　　2.3、UNION，聯合查詢
　　2.4、DEPENDENT UNION，子查詢中的聯合查詢
　　2.5、UNION RESULT，聯合的結果集
　　2.6、SUBQUERY，第一個子查詢
　　2.7、 DEPENDENT SUBQUERY，子查詢中第一句
　　2.8、DERIVED，派生表

3.Table，顯示這一行的數據是關於哪張表的.
4.Type，這列很重要,顯示了連接使用了哪種類別,有無使用索引.從最好到最差的連接類型為const、eq_reg、ref、range、indexhe和ALL

　　4.1、system, const聯接類型的一個特例。表僅有一行滿足條件

　　4.2、const，表最多有一個匹配行，它將在查詢開始時被讀取。因為僅有一行，在這行的列值可被優化器剩余部分認為是常數。const表很快，因為它們只讀取一次！

　　4.3、eq_ref，對於每個來自於前面的表的行組合，從該表中讀取一行。這可能是最好的聯接類型，除了const類型。它用在一個索引的所有部分被聯接使用並且索引是UNIQUE或PRIMARY KEY。eq_ref可以用於使用= 操作符比較的帶索引的列。

比較值可以為常量或一個使用在該表前面所讀取的表的列的表達式。

　　4.4、.ref，對於每個來自於前面的表的行組合，所有有匹配索引值的行將從這張表中讀取。如果聯接只使用鍵的最左邊的前綴，或如果鍵不是UNIQUE或PRIMARY KEY（換句話說，如果聯接不能基於關鍵字選擇單個行的話），則使用ref。

　　　　 如果使用的鍵僅僅匹配少量行，該聯接類型是不錯的。ref可以用於使用=或<=>操作符的帶索引的列。

　　4.5、 ref_or_null，該聯接類型如同ref，但是添加了MySQL可以專門搜索包含NULL值的行。在解決子查詢中經常使用該聯接類型的優化。

　　4.6、index_merge，該聯接類型表示使用了索引合並優化方法。在這種情況下，key列包含了使用的索引的清單，key_len包含了使用的索引的最長的關鍵元素。

　　4.7、unique_subquery，該類型替換了下面形式的IN子查詢的ref。value IN (SELECT primary_key FROM single_table WHERE some_expr) unique_subquery是一個索引查找函數，可以完全替換子查詢，效率更高。

　　4.8、index_subquery，該聯接類型類似於unique_subquery。可以替換IN子查詢

　　4.9、range、只檢索給定範圍的行，使用一個索引來選擇行。key列顯示使用了哪個索引。key_len包含所使用索引的最長關鍵元素。在該類型中ref列為NULL。

　　4.10、index、該聯接類型與ALL相同，除了只有索引樹被掃描。這通常比ALL快，因為索引文件通常比數據文件小。

　　4.11、ALL，對於每個來自於先前的表的行組合，進行完整的表掃描。如果表是第一個沒標記const的表，這通常不好，並且通常在它情況下很差。通常可以增加更多的索引而不要使用ALL，使得行能基於前面的表中 的常數值或列值被檢索出。

5.possible_keys，possible_keys列指出MySQL可能使用哪個索引在該表中找到行。
6. Key，key列顯示MySQL實際使用的鍵（索引）。
7.key_len，使用的索引的長度。在不損失精確性的情況下，長度越短越好
8. Ref，ref列顯示使用哪個列或常數與key一起從表中選擇行。
9. Rows，rows列顯示MySQL認為它執行查詢時必須檢查的行數。
10. Extra，該列包含MySQL解決查詢的詳細信息,下面詳細。

Extra，這個列可以顯示的信息非常多，有幾十種。常用如下：

　　10.1. Distinct, 一旦MYSQL找到了與行相聯合匹配的行，就不再搜索了

　　10.2. Not exists ，使用了反連接，先查詢外表，再查詢內表

　　10.3. Range checked for each Record（index map:#） 沒有找到理想的索引，因此對於從前面表中來的每一個行組合，MYSQL檢查使用哪個索引，並用它來從表中返回行。這是使用索引的最慢的連接之一

　　10.4. Using filesort 看到這個的時候，查詢需要優化。MYSQL需要進行額外的步驟來發現如何對返回的行排序。它根據連接類型以及存儲排序鍵值和匹配條件的全部行的行指針來排序全部行

　　10.5. Using index 列數據是從僅僅使用了索引中的信息而沒有讀取實際的行動的表返回的，這發生在對表的全部的請求列都是同一個索引的部分的時候

　　10.6. Using temporary 看到這個的時候，查詢需要優化。這裏，MYSQL需要創建一個臨時表來存儲結果，這通常發生在對不同的列集進行ORDER BY上，而不是GROUP BY上

　　10.7. Using where 使用了WHERE從句來限制哪些行將與下一張表匹配或者是返回給用戶。如果不想返回表中的全部行，並且連接類型ALL或index，這就會發生，或者是查詢有問題

　　10.8. firstmatch(tb_name)：5.6.x開始引入的優化子查詢的新特性之一，常見於where字句含有in()類型的子查詢。如果內表的數據量比較大，就可能出現這個.

　　10.9. loosescan(m..n)：5.6.x之後引入的優化子查詢的新特性之一，在in()類型的子查詢中，子查詢返回的可能有重復記錄時，就可能出現這個

重要：執行計劃的各列說明裏面標紅的項都是我們在做SQL執行計劃分析時應該重點關註的項

4. MySQL執行計劃的局限

?EXPLAIN不會告訴你關於觸發器、存儲過程的信息或用戶自定義函數對查詢的影響情況

?EXPLAIN不考慮各種Cache

?EXPLAIN不能顯示MySQL在執行查詢時所作的優化工作

?部分統計信息是估算的，並非精確值

?EXPALIN只能解釋SELECT操作，其他操作要重寫為SELECT後查看執行計劃

三、優化示例

1. 分頁特殊處理

效率低的

Select * from fentrust e limit 4100000, 10

效率最高的

Select * from fentrust e
Inner join (select fid from fentrust limit 4100000, 10) a on a.fid = e.fid

原理：

1.對fid建了索引，select fid from fentrust limit 4100000, 10 走的是覆蓋索引不經過磁盤，直接在索引裏面就獲取到值，速度更快

2.mysql查詢的時候會先查詢子查詢，select fid from fentrust limit 4100000, 10 先查出來10條記錄，再把這10條記錄關聯查詢就更快了

2. 善用子查詢

效率低的

SELECT
    wu.fuid,
    wu.fwid,
    v.fvi_fid,
    v.fvi2_fid,
    SUM(l.fcount),
    SUM(l.famount),
    SUM(
        l.famount / v.famount * v.ffees
    ),
    v.fentrustType,
    0,
    ‘2018 - 01 - 01‘, NOW(), SUM(v.fleftCount), SUM(v.fleftfees), 0
FROM fentrustlog_vcoin 
INNER JOIN fentrust_vcoin v ON l.fen_fid = v.fid
INNER JOIN fwebsite_user wu ON wu.fuid = v.fus_fid
WHERE l.fid NOT IN(SELECT l2.fid FROM fentrustlog_vcoin l2, fentrust_vcoin v2
WHERE l2.fen_fid = v2.fid AND l2.fprize = l.fprize AND l2.fcount = l.fcount AND l2.fcreateTime = l.fcreateTime
AND l2.fid <> l.fid AND v2.fus_fid = v.fus_fid and wu.fwid=1)
GROUP BY wu.fuid, wu.fwid, v.fvi_fid, v.fvi2_fid, v.fentrustType

效率最高的

SELECT
    v.fus_fid,
    1,
    v.fvi_fid,
    v.fvi2_fid,
    SUM(v.fcount - v.fleftCount),
    SUM(v.fsuccessAmount),
    SUM(v.ffees - v.fleftfees),
    v.fentrustType,
    0,
    ‘2018 - 01 - 01‘, NOW(), SUM(v.fleftCount), SUM(v.fleftfees), 0
FROM fentrust_vcoin v
where v.fstatus > 1 and v.FUs_fId in (select fuid from fwebsite_user wu where wu.fwid = 1)
and v.fVi2_fId in (select fvid from fwebsite_coin where fwebsite_id = 1)
GROUP BY v.fentrustType, v.fvi_fid, v.fvi2_fid, v.fus_fid

原理：

首先分析一下表是不是必要的，從其他表裏面能取到需要的字段，能的話就刪除多余的表

善於使用子查詢，子查詢比join快，雖然規律不絕對，但對大表多數有效

mysql查詢時會先走子查詢

3. Where條件順序

效率低的

SELECT * FROM `fentrustlog` e WHERE e.fcount > 1000 and e.famount > 300000

效率最高的

SELECT * FROM `fentrustlog` e WHERE  e.famount > 300000 and e.fcount > 1000 

原理：

e.fcount > 1000：48萬行

e.famount > 300000： 24行

誰先誰後？

結果是不太有效

where條件盡量把小結果集放在前面，原因是查詢時會先過濾出小結果再過濾出大結果裏面滿足條件的值效果更好

4. 大事務問題

盡量避免大事務操作，提高系統並發能力。有時無法避免，改用定時器延遲處理

何為大事務問題呢？即操作千萬級的數據的插入、更新、刪除、查詢，這個事時候分析一下是否可以使用定時器處理，比如每天淩晨才開始操作

5. 不走索引的情況

SELECT famount FROM fentrust WHERE famount +10=30;-- 不會使用索引,因為所有索引列參與了計算

SELECT famount FROM fentrust WHERE LEFT(fcreateTime,4) <1990; -- 不會使用索引,因為使用了函數運算,原理與上面相同

SELECT * FROM fuser WHERE floginname LIKE‘138% -- 走索引 會走B-Tree索引的一部分，具體請百度B-Tree的結果圖，或者在前一篇文章也有介紹

SELECT * FROM fuser WHERE floginname LIKE "%7488%" -- 不走索引 -- 正則表達式不使用索引,這應該很好理解,所以為什麽在SQL中很難看到regexp關鍵字的原因 -- 字符串與數字比較不使用索引;

EXPLAIN SELECT * FROM a WHERE ‘a‘=1 -- 不走索引

select * from fuser where floginname=xxx or femail=xx or fstatus=1 --如果條件中有or,即使其中有條件帶索引也不會使用。換言之,就是要求使用的所有字段,都必須建立索引, 我們建議大家盡量避免使用or 關鍵字

如果mysql估計使用全表掃描要比使用索引快,則不使用索引

四、千萬級數據優化

1. 網上收集的一些大數據表優化的策略

1.對查詢進行優化，應盡量避免全表掃描，首先應考慮在 where 及 order by 涉及的列上建立索引。

2.應盡量避免在 where 子句中對字段進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃描，如：select id from t where num is null可以在num上設置默認值0，確保表中num列沒有null值，然後這樣查詢：select id from t where num=0

3.應盡量避免在 where 子句中使用!=或<>操作符，否則引擎將放棄使用索引而進行全表掃描。

4.應盡量避免在 where 子句中使用or 來連接條件，否則將導致引擎放棄使用索引而進行全表掃描，如：select id from t where num=10 or num=20可以這樣查詢：select id from t where num=10 union all select id from t where num=20

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

6.下面的查詢也將導致全表掃描：select id from t where name like ‘李%‘若要提高效率，可以考慮全文檢索。

7. 如果在 where 子句中使用參數，也會導致全表掃描。因為SQL只有在運行時才會解析局部變量，但優化程序不能將訪問計劃的選擇推遲到運行時；它必須在編譯時進行選擇。然而，如果在編譯時建立訪問計劃，變量的值還是未知的，因而無法作為索引選擇的輸入項。如下面語句將進行全表掃描：select id from t where num=@num可以改為強制查詢使用索引：select id from t with(index(索引名)) where num=@num

8.應盡量避免在 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 name like ‘abc%‘

10.不要在 where 子句中的“=”左邊進行函數、算術運算或其他表達式運算，否則系統將可能無法正確使用索引。

11.在使用索引字段作為條件時，如果該索引是復合索引，那麽必須使用到該索引中的第一個字段作為條件時才能保證系統使用該索引，否則該索引將不會被使用，並且應盡可能的讓字段順序與索引順序相一致。

12.不要寫一些沒有意義的查詢，如需要生成一個空表結構：select col1,col2 into #t from t where 1=0

這類代碼不會返回任何結果集，但是會消耗系統資源的，應改成這樣：

create table #t(...)

13.很多時候用 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)

14.並不是所有索引對查詢都有效，SQL是根據表中數據來進行查詢優化的，當索引列有大量數據重復時，SQL查詢可能不會去利用索引，如一表中有字段sex，male、female幾乎各一半，那麽即使在sex上建了索引也對查詢效率起不了作用。

15. 索引並不是越多越好，索引固然可 以提高相應的 select 的效率，但同時也降低了 insert 及 update 的效率，因為 insert 或 update時有可能會重建索引，所以怎樣建索引需要慎重考慮，視具體情況而定。一個表的索引數最好不要超過6個，若太多則應考慮一些不常使用到的列上建的索引是否有 必要。

16. 應盡可能的避免更新 clustered 索引數據列，因為 clustered索引數據列的順序就是表記錄的物理存儲順序，一旦該列值改變將導致整個表記錄的順序的調整，會耗費相當大的資源。若應用系統需要頻繁更新 clustered索引數據列，那麽需要考慮是否應將該索引建為 clustered 索引。

17.盡量使用數字型字段，若只含數值信息的字段盡量不要設計為字符型，這會降低查詢和連接的性能，並會增加存儲開銷。這是因為引擎在處理查詢和連接時會逐個比較字符串中每一個字符，而對於數字型而言只需要比較一次就夠了。

18.盡可能的使用 varchar/nvarchar 代替 char/nchar ，因為首先變長字段存儲空間小，可以節省存儲空間，其次對於查詢來說，在一個相對較小的字段內搜索效率顯然要高些。

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

20.盡量使用表變量來代替臨時表。如果表變量包含大量數據，請註意索引非常有限（只有主鍵索引）。

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.盡量避免向客戶端返回大數據量，若數據量過大，應該考慮相應需求是否合理。

2. 批量刪除，而不一次性

while(true){

 　　//每次只做1000條
　　 “delete from logs where log_date <= ’2012-11-01’ limit 1000”;
 　　if(mysql_affected_rows == 0){

　　 　　//刪除完成，退出！
　　 　　break；
　　}

        //每次暫停一段時間，釋放表讓其他進程/線程訪問。
        Thread.sleep(5000L)

}

3. 大數據表優化

建立匯總表

建立流水表

分表分庫

說明：最開始的時候不要考慮分庫分表，可以先采用匯總表的策略，何為匯總表呢？就是把基礎數據向上一個維度統計，比如有一些數據是按照小時新增的，那就可以先按照天來匯總，在天的基礎上再用程序來統計，具體的統計維度得根據業務來

性能優化系列七：SQL優化