㈠ sql優化（二）
SQL優化一： sql優化（一）
上片文章已經詳細介紹了explain各個欄位的含義，以及什麼情況應該建立索引，什麼情況不需要建立索引以及sql語句性能的判斷依據，接下來我介紹下如何合理的建立索引。
sql語句：select id，author_id from article where category_id = 1 and comments>1 order by views desc limit 1;
分析：首先我們根據where後面的條件建立符合索引，然後根據order by後面的欄位建立索引，因此建立索引idx_article_ccv，即以（category_id，comments，views）數據列建立復合索引，但由於comments是一個范圍，按照BTree索引的原理，先排序category_id,如果遇到相同的category_id則再排序comments，如果遇到相同的comments則再排序views，又因為comments欄位在復合索引里處於中間位置，而comments>1是一個條件（是一個范圍值），在復合索引的一個范圍值的數據列後面的索引全部失效，mysql無法利用索引再對後面的views部分進行檢索，也就是說views無法按照索引排序，所以explain下此sql語句，type為range，extra使用的是Using filesort，這是比較糟糕的。所以我們放棄comments這個范圍欄位，建立索引idx_article_cv，即以（category_id，views）數據列建立復合索引，explain 此sql，type變成了ref，extra的using filesort也變成了using index，這就變得好多了。
索引：idx_article_cv，即以（category_id，views）數據列建立復合索引
前段時間做了一個銷售精細化項目，是公司crm項目的一個大模塊，大致就是為銷售人員制定指標，實現銷售目標從區域到團到業務員到客戶，實時跟蹤業務員所負責客戶的下單量的情況。這就存在許多關聯關系，區域-團，團-業務員，業務員-客戶，這使得sql常常需要關聯多張表。
sql語句：SELECT
tu.fuserid,
tu.faccount,
tu.fphone,
tu.fcertificationtype,
tu.fcertificatename,
tu.fkeyarea,
tu.fkeyareatext,
DATE_FORMAT(tcr.fupdatetime,'%Y-%m-%d %H:%i:%s') as fupdatetime,
tag.forggroupid,
tag.forggroupname,
tug.forguserid,
tug.fusername,
tug.fuserphone,
tag.fcitycode
FROM t_finedt_user AS tu
LEFT JOIN t_finedt_customer_relation AS tcr
ON tu.fuserid = tcr.fuserid
LEFT JOIN t_finedt_usergroup AS tug
ON tcr.forguserid = tug.forguserid
and tcr.forggroupid = tug.forggroupid
LEFT JOIN t_finedt_areagroup AS tag
ON tug.forggroupid = tag.forggroupid
where tu.fkeyarea=? and tu.fuserid=? and tug.forggroupid = ?
分析：上面的sql是左連接，左邊的表一定是全表查詢，所以要建立右邊表對應關聯欄位的索引，在表t_finedt_user上建立tu_fuserid_fkeyarea索引，即以(fuserid，fkeyarea)欄位建立索引，在表t_finedt_customer_relation 上建立tcr_forguserid_forggroupid索引，即以（forguserid，forggroupid）欄位建立索引，在表t_finedt_usergroup 上建立tug_forguserid_forggroupid索引，即以（forguserid,forggroupid)欄位建立索引，在表t_finedt_areagroup上建立tag_forggroupid索引，即以（forggroupid)欄位建立索引。建立索引後，sql查詢速度明顯快了很多
索引：tcr_forguserid_forggroupid，tu_fuserid_fkeyarea，tug_forguserid_forggroupid，tag_forggroupid
1、盡可能減少join語句中的NestedLoop的循環次數，永遠用小結果集驅動大結果集
2、優先優化NestedLoop的內層循環
3、保證join語句總被驅動表上的join欄位已經被索引
4、當無法保證被驅動表join條件欄位被索引，且內存資源充足的前提下，不要太吝嗇joinBuffer的設置
1、全值匹配我最愛
2、最佳左前綴原則——如果索引了多列，要遵守最左前綴原則，指的是查詢從索引的最左前列開始並且不跳過索引中的列
3、並在索引列上做任何操作（計算、函數、自動or手動類型轉換），這些會導致索引失效而轉向全表掃描
4、存儲引擎不能使用索引中范圍條件右邊的列，范圍之後的索引全失效
5、盡量使用覆蓋索引（之訪問索引的查詢（索引列和查詢的列一致）），減少select *
6、mysql在使用不等於（！=、>、<）的時候無法使用索引會導致全表掃描。
7、is null、is not null也無法使用索引。
8、like以通配符開頭（"%abc.."），mysql索引失效也會變成全表掃描的操作。
9、字元串不加單引號也會引起索引失效
10、少用or，用它來連接時會索引失效。
1、對於單值索引，盡量選擇針對當前query過濾性更好的索引
2、在選擇組合索引的時候，當前query中過濾性最好的欄位在索引欄位順序中，位置越靠前越好
3、在選擇組合索引的時候，盡量選擇盡可能包含當前query中的where字句中更多欄位的索引
4、盡可能通過分析統計信息和調整query的寫法來達到選擇合適索引的目的。
全值匹配我最愛，最左前綴要遵守
帶頭大哥不能死，中間兄弟不能斷
索引列上少計算，范圍之後全失效
like百分寫最右，覆蓋索引不寫里
不等空值還有or，索引失效要少用
var引號不可丟，sql高級也不難
㈡ 如何優化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:mysql所在伺服器內核 優化；此優化可由系統運維人員完成
㈣ SQL語句優化問題
先用一個子查詢判斷+統計結果 然後外面套一個查詢
select from orders o, (select max(id) mid,sum(qty) from orders group by shipp_house ) A
where o.id=a.mid
只是提供一個思路
㈤ SQL優化問題（求大神）
selectDate,id,Namefrom(
SELECTDate,Avg(id)id,Name
,row_number()over()asseq
FROM#
GROUPBYNAME,Date
)Fwhereseq=1
這個語句只會進行一次表掃描(或索引掃描)。而你原來的語句，會進行兩次表掃描(或索引掃描)和一次join。
㈥ SQL 語句優化問題
事實上，這樣的擔心是不必要的。SQL
SERVER中有一個「查詢分析優化器」，它可以計算出WHERE子句中的搜索條件並確定哪個索引能縮小表掃描的搜索空間，也就是說，它能實現自動優化。
雖然查詢優化器可以根據WHERE子句自動的進行查詢優化，但仍然有必要了解一下「查詢優化器」的工作原理，如非這樣，有時查詢優化器就會不按照您的本意進行快速查詢。
在查詢分析階段，查詢優化器查看查詢的每個階段並決定限制需要掃描的數據量是否有用。如果一個階段可以被用作一個掃描參數（SARG），那麼就稱之為可優化的，並且可以利用索引快速獲得所需數據。
SARG的定義：用於限制搜索的一個操作，因為它通常是指一個特定的匹配，一個值得范圍內的匹配或者兩個以上條件的AND連接。形式如下：
列名
操作符
<常數
或
變數>或<常數
或
變數>
操作符列名
列名可以出現在操作符的一邊，而常數或變數出現在操作符的另一邊。如：
Name=』張三』價格>5000
5000<價格
Name=』張三』
and
價格>5000
如果一個表達式不能滿足SARG的形式，那它就無法限制搜索的范圍了，也就是SQL
SERVER必須對每一行都判斷它是否滿足WHERE子句中的所有條件。所以一個索引對於不滿足SARG形式的表達式來說是無用的。
常見的SARG判別經驗：
Like語句是否屬於SARG取決於所使用的通配符的類型
如：name
like
『張%』，這就屬於SARG
而：name
like
『%張』，就不屬於SARG。
原因是通配符%在字元串的開通使得索引無法使用。
or
會引起全表掃描。
Name
=
』張三』
AND
價格>5000，符合SARG，
Name
=
』張三』
OR
價格>5000，不符合SARG。
原因是使用or會引起全表掃描。
非操作符、函數引起的不滿足SARG形式的語句。
不滿足SARG形式的語句最典型的情況就是包括非操作符的語句，如：NOT、!=、<>、!<、!>、NOT
EXISTS、NOT
IN、NOT
LIKE等，另外還有函數。下面就是幾個不滿足SARG形式的例子：
ABS(價格)<5000
Name
like
『%三』
有些表達式，如：WHERE
價格*2>5000
SQL
SERVER也會認為是SARG，SQL
SERVER會將此式轉化為：價格>5000/2
但不推薦這樣使用，因為有時SQL
SERVER不能保證這種轉化與原始表達式是完全等價的。
㈦ sql優化的幾種方法面試
1.你把學校裡面學的東西都弄通，弄懂就可以了，基本的概念和原理都能說出來，如你說的sql優化就是：為資料庫建立索引，如何提高檢索速度之類的問題。教科書上都有說啊。
2.面試不是說一定要什麼都懂才能去面的，你要找多一點面試經驗，面試經常問什麼問題，比如指針，鏈表等，有針對性地准備一下，不用全部一骨碌地看。
3.積累經驗和編程作品，多做項目，自己多寫些程序。面試就有了籌碼。
㈧ sql期末考試試題及答案
查詢題：1).select*fromEMPwhereDEPTNO='20';2).select*fromEMPwhereENAMElike'MA%';3).select*fromEMPorderbyJOB;4).selectb.DNAME,COUNT(a.*)asnumfromEMPaleftjoinDEPTbona.DEPTNO=b.DEPTNOgroupbyb.DNAME5).select*fromEMPwhereSAL>(selectmax(SAL)asSALfromEMPwhereDEPTNO='20');程序題：1).函數：CREATEFUNCTION[SumN](@nINT)RETURNSINTASBEGINdeclare@outINT,@iintset@out=0set@i=1while@i<=@nbeginset@out=@out+@iset@i=@i+1endreturn(@out)END2).存儲過程：CREATEPROCEDURE[emp_info](@nDECIMAL(2))ASselect*fromEMPwhereDEPTNO=@n視圖和索引1).CREATEVIEW[emp10_view]ASselect*fromEMPwhereDEPTNO='10'2).ALTERTABLE[EMP]ADDCONSTRAINT[IX_Empno]PRIMARYKEYCLUSTERED([empno]ASC)
㈨ 一些SQL的試題
1.應用程序
2.實體完整性
3.distince
4.
5.create Nonclustered index IDX_authors on authors(州名列,城市名列)
6.創建表
7.select 列名 from 表名
8.sum()
9.top
10.alter procere
11.ltrim()
12.declare @變數名 數據類型
13.where
14.from
15.order by
16.cast(表達式 as 數據類型)
17.count()
18.drop procere 存儲過程名
19.創建資料庫
20.價格大於15美元的所有數據
21.資料庫
22.rollback
23.
24.服務管理器
25.
26.數據冗餘（備份）
27.3
28.資料庫
29.應用程序
30.drop table
33.操作系統
許可權
1.
2.是並發控制的單位，是用戶定義的一個操作序列,具有原子性，一致性，隔離性，持續性四個特性。
3.共享鎖（S鎖）：如果事務T對數據A加上共享鎖後，則其他事務只能對A再加共享鎖，不能加排他鎖.
獲准共享鎖的事務只能讀數據，不能修改數據。
4.
5.
1.存儲過程可以使得程序執行效率更高、安全性更好，因為過程建立之後 已經編譯並且儲存到資料庫，直接寫sql就需要先分析再執行因此過程效率更高，直接寫sql語句會帶來安全性問題，如：sql注入
2.建立過程不會很耗系統資源，因為過程只是在調用才執行。
6.聚簇索引是一種對磁碟上實際數據重新組織以按指定的一個或多個列的值排序。
7.
8.是並發控制的單位，是用戶定義的一個操作序列,具有原子性，一致性，隔離性，持續性四個特性。
BEGIN TRAN [Tran_name]開始事務
COMMIT TRAN [Tran_name]事務完成提交事務
9.存儲過程是由流控制和SQL語句書寫的過程，這個過程經編譯和優化後存儲在資料庫伺服器中，應用程序使用時只要調用即可。
10.增量備份：是針對於上一次備份(無論是哪種備份):備份上一次備份後，所有發生變化的文件。
12.原子性，要麼都做，要麼不做。
13.排它鎖若事務T對數據對象A加上X鎖，則只允許T讀取和修改A，其它任何事務都不能再對A加任何類型的鎖，直到T釋放A上的鎖。
它防止任何其它事務獲取資源上的鎖，直到在事務的末尾將資源上的原始鎖釋放為止。
14.分布式資料庫系統通常使用較小的計算機系統，每台計算機可單獨放在一個地方，每台計算機中都有DBMS的一份完整拷貝副本，並具有自己局部的資料庫，位於不同地點的許多計算機通過網路互相連接，共同組成一個完整的、全局的大型資料庫。
15.
17同2，18同8
19.DBMS資料庫管理系統，DBA資料庫管理員
20.1對1，一個學生對應一個學號
1對多 一個學生對應多門功課
多對多 商品與廠商
（備註：只能做這么多了，很長時間沒看書了，有時間可以看看<資料庫系統概論>薩師煊 王珊 高等教育出版社，很不錯的一本書哦。上有你要的答案，特別是簡答題。）
21.
22.資料庫完整性，對資料庫提出的某種約束條件或規則。
分三種：實體完整性，參照完整性，用戶自定義完整性
23.
24.原則如下：
●在經常進行連接，但是沒有指定為外鍵的列上建立索引，而不經常連接的欄位則由優化器自動生成索引。
●在頻繁進行排序或分組（即進行group by或order by操作）的列上建立索引。
●在條件表達式中經常用到的不同值較多的列上建立檢索，在不同值少的列上不要建立索引。比如在雇員表的「性別」列上只有「男」與「女」兩個不同值，因此就無必要建立索引。如果建立索引不但不會提高查詢效率，反而會嚴重降低更新速度。
●如果待排序的列有多個，可以在這些列上建立復合索引（compound index）。
26。聚集索引確定表中數據的物理順序。由於聚集索引規定數據在表中的物理存儲順序，因此一個表只能包含一個聚集索引。但該索引可以包含多個列（組合索引）
非聚集索引一種索引，該索引中索引的邏輯順序與磁碟上行的物理存儲順序不同。一個表可以有多個聚集索引
㈩ SQL執行與優化
SQL優化
執行計劃,表關聯查詢順序,優化策略與思路
下面再向前走一些，容我根據自己的認識說一下查詢執行的流程是怎樣的：
1.連接
1.1客戶端發起一條Query請求，監聽客戶端的『連接管理模塊』接收請求
1.2將請求轉發到『連接進/線程模塊』
1.3調用『用戶模塊』來進行授權檢查
1.4通過檢查後，『連接進/線程模塊』從『線程連接池』中取出空閑的被緩存的連接線程和客戶端請求對接，如果失敗則創建一個新的連接請求
2.處理
2.1先查詢緩存，檢查Query語句是否完全匹配，接著再檢查是否具有許可權，都成功則直接取數據返回
2.2上一步有失敗則轉交給『命令解析器』，經過詞法分析，語法分析後生成解析樹
2.3接下來是預處理階段，處理解析器無法解決的語義，檢查許可權等，生成新的解析樹
2.4再轉交給對應的模塊處理
2.5如果是SELECT查詢還會經由『查詢優化器』做大量的優化，生成執行計劃
2.6模塊收到請求後，通過『訪問控制模塊』檢查所連接的用戶是否有訪問目標表和目標欄位的許可權
2.7有則調用『表管理模塊』，先是查看table cache中是否存在，有則直接對應的表和獲取鎖，否則重新打開表文件
2.8根據表的meta數據，獲取表的存儲引擎類型等信息，通過介面調用對應的存儲引擎處理
2.9上述過程中產生數據變化的時候，若打開日誌功能，則會記錄到相應二進制日誌文件中
3.結果
3.1Query請求完成後，將結果集返回給『連接進/線程模塊』
3.2返回的也可以是相應的狀態標識，如成功或失敗等
3.3『連接進/線程模塊』進行後續的清理工作，並繼續等待請求或斷開與客戶端的連接
接下來再走一步，讓我們看看一條SQL語句的前世今生。
首先看一下示例語句
示例語句
執行順序
SQL解析
1. FROM
當涉及多個表的時候，左邊表的輸出會作為右邊表的輸入，之後會生成一個虛擬表VT1。
(1-J1)笛卡爾積
計算兩個相關聯表的笛卡爾積(CROSS JOIN) ，生成虛擬表VT1-J1。
兩次全表掃描
哈希索引,查找復雜度都是 O(1) 。
2. WHERE
對VT1過程中生成的臨時表進行過濾，滿足WHERE子句的列被插入到VT2表中。
注意：
此時因為分組，不能使用聚合運算；也不能使用SELECT中創建的別名；
與ON的區別：
如果有外部列，ON針對過濾的是關聯表，主表（保留表）會返回所有的列；
如果沒有添加外部列，兩者的效果是一樣的；
應用：
對主表的過濾應該放在WHERE；
對於關聯表，先條件查詢後連接則用ON，先連接後條件查詢則用WHERE；
hash join 哈希連接 驅動表和被驅動表都只會訪問0次或1次
應用場景:一個大表一個小表/表上沒有索引/返回結果集比較大
3. GROUP BY
這個子句會把VT2中生成的表按照GROUP BY中的列進行分組。生成VT3表。
注意：
其後處理過程的語句，如SELECT,HAVING，所用到的列必須包含在GROUP BY中，對於沒有出現的，得用聚合函數；
原因：
GROUP BY改變了對表的引用，將其轉換為新的引用方式，能夠對其進行下一級邏輯操作的列會減少；
原作者的理解是：
根據分組欄位，將具有相同分組欄位的記錄歸並成一條記錄，因為每一個分組只能返回一條記錄，除非是被過濾掉了，而不在分組欄位裡面的欄位可能會有多個值，多個值是無法放進一條記錄的，所以必須通過聚合函數將這些具有多值的列轉換成單值；
GROUP BY 重新聚合查詢
4. HAVING
這個子句對VT3表中的不同的組進行過濾，只作用於分組後的數據，滿足HAVING條件的子句被加入到VT4表中。
7.LIMIT
LIMIT子句從上一步得到的VT6虛擬表中選出從指定位置開始的指定行數據。
注意：
offset和rows的正負帶來的影響；
當偏移量很大時效率是很低的，可以這么做：
採用子查詢的方式優化，在子查詢里先從索引獲取到最大id，然後倒序排，再取N行結果集
採用INNER JOIN優化，JOIN子句里也優先從索引獲取ID列表，然後直接關聯查詢獲得最終結果
當前未用到索引,
三次full scan , table1 AS a / table2 AS b / GROUP BY
盡量少做重復的工作
控制同一語句的多次執/減少多次的數據轉換/
杜絕不必要的子查詢和連接表，子查詢在執行計劃一般解釋成外連接，多餘的連接表帶來額外的開銷
關於臨時表和表變數的選擇
臨時表產生使用SELECT INTO和CREATE TABLE + INSERT INTO的選擇，一般情況下，SELECT INTO會比CREATE TABLE + INSERT INTO的方法快很多，但是SELECT INTO會鎖定TEMPDB的系統表SYSOBJECTS、SYSINDEXES、SYSCOLUMNS，在多用戶並發環境下，容易阻塞其他進程，所以建議，在並發系統中，盡量使用CREATE TABLE + INSERT INTO，而大數據量的單個語句使用中，使用SELECT INTO。
子查詢的用法
相關子查詢可以用IN、NOT IN、EXISTS、NOT EXISTS引入
NOT IN、NOT EXISTS的相關子查詢可以改用LEFT JOIN代替寫法
如果保證子查詢沒有重復 ，IN、EXISTS的相關子查詢可以用INNER JOIN 代替
IN``的相關子查詢用EXISTS代替
不要用 COUNT (*)的子查詢判斷是否存在記錄，最好用 LEFT` `JOIN 或者EXISTS，比如有人寫這樣的語句：
建立索引後，並不是每個查詢都會使用索引，在使用索引的情況下，索引的使用效率也會有很大的差別。只要我們在查詢語句中沒有強制指定索引，
不要對索引欄位進行運算，而要想辦法做變換
不要對索引欄位進行格式轉換
不要對索引欄位使用函數
不要對索引欄位進行多欄位連接
join關聯查詢的計算是很復雜的，特別是數據量比較大的情況下，實際情況還是拆解較快的
Join拆解的核心就是利用In關鍵字
要麼用空間換時間，要麼用時間換空間
多表連接的連接條件對索引的選擇有著重要的意義，所以我們在寫連接條件條件的時候需要特別注意。
A、多表連接的時候，連接條件必須寫全，寧可重復，不要缺漏。
B、連接條件盡量使用聚集索引
C、注意ON、WHERE和HAVING部分條件的區別
ON是最先執行， WHERE次之，HAVING最後，因為ON是先把不符合條件的記錄過濾後才進行統計，它就可以減少中間運算要處理的數據，按理說應該速度是最快的，WHERE也應該比 HAVING快點的，因為它過濾數據後才進行SUM，在兩個表聯接時才用ON的，所以在一個表的時候，就剩下WHERE跟HAVING比較了
考慮聯接優先順序：
(1)INNER JOIN
(2)LEFT JOIN (註：RIGHT JOIN 用 LEFT JOIN 替代)
(3)CROSS JOIN
索引並不適用於所有情況：a.少量數據；b.頻繁進行改動的欄位，不適合做索引；c.很少使用的欄位，不需要加索引
索引會提高數據查詢效率，但是會降低「增、刪、改」的效率。當不使用索引的時候，我們進行數據的增刪改，只需要操作源表即可，但是當我們添加索引後，不僅需要修改源表，也需要再次修改索引，很麻煩。
先執行順序, 是否走索引, 有無類型轉換
18000 字的SQL優化大全
步步深入：MySQL架構總覽->查詢執行流程->SQL解析順序
MySQL索引總結（4）——btree與hash區別