引言
以前剛開始做項目的時候，開發經驗尚淺，遇到問題需求只要把結果查詢出來就行,至於查詢的效率可能就沒有太多考慮,數據少的時候還好,數據一多,效率問題就顯現出來了。每次遇到查詢比較慢時，項目經理就會問：是不是又用select * 了？查詢條件有沒有加索引？一語驚醒夢中人，趕緊檢查..果然如此！
有時我們寫sql語句時，沒有考慮它的性能或者完全沒有優化意識，雖然能暫時滿足基本功能，等到數據量大時，后果可想而知。
下面我們就聊一聊sql優化的一些常見方法：
1、sql語句模型結構優化指導
A. ORDER BY + LIMIT組合的索引優化
SELECT [column1],[column2],…. FROM [TABLE] ORDER BY [sort] LIMIT [offset],[LIMIT]; sort上簡索引
B. WHERE + ORDER BY + LIMIT組合的索引優化
SELECT [column1],[column2],…. FROM [TABLE] WHERE [columnX] = [VALUE] ORDER BY [sort] LIMIT [offset],[LIMIT];
建立一個聯合索引(columnX,sort)
C. WHERE+ORDER BY多個欄位+LIMIT
SELECT * FROM [table] WHERE uid=1 ORDER BY x,y LIMIT 0,10; 建立復合索引(uid,x,y)
2、復合索引(形如(x,y,uid)索引的索引)
select* from users where area =’beijing’ and age=22;
建立索引（area,age,salary）,其相當於創建了（area,age,salary）,(area,age),(area)三個索引，這樣稱為最佳左前綴特性。
3、like語句優化
SELECT id FROM A WHERE name like '%abc%'
由於abc前面用了“%”，因此該查詢必然走全表查詢，除非必要，否則不要在關鍵詞前加%,優化成如下
SELECT id FROM A WHERE name like 'abc%'
4、where子句使用 ！= 或 <> 操作符優化
在where子句中使用 ！= 或 <>操作符，索引將被放棄使用，會進行全表查詢。
如SQL:SELECT id FROM A WHERE ID != 5
優化成：SELECT id FROM A WHERE ID>5 OR ID<5
5、盡量避免在 where 子句中對字段進行 null 值判斷(IS NULL 或 IS NOT NULL)，因為空判斷將導致全表掃描，而不是索引掃描。對於空判斷這種情況，可以考 慮對這個列創建數據庫默認值。
在where子句中使用 IS NULL 或 IS NOT NULL 判斷，索引將被放棄使用，會進行全表查詢。
如SQL:SELECT id FROM A WHERE num IS NULL 優化成num上設置默認值0，確保表中num沒有null值，
然后SQL為：SELECT id FROM A WHERE num=0
6、where子句使用or的優化
很多時候使用union all 或 nuin(必要的時候)的方式替換“or”會得到更好的效果。where子句中使用了or,索引將被放棄使用。
如SQL:SELECT id FROM A WHERE num =10 or num = 20
優化成：SELECT id FROM A WHERE num = 10 union all SELECT id FROM A WHERE num=20
7、where子句使用IN 或 NOT IN的優化
in和not in 也要慎用，否則也會導致全表掃描。
方案一：between替換in
如SQL:SELECT id FROM A WHERE num in(1,2,3)
優化成：SELECT id FROM A WHERE num between 1 and 3
方案二：exist替換in
如SQL:SELECT id FROM A WHERE num in(select num from b )
優化成：SELECT id FROM A WHERE num exists(select 1 from B where B.num = A.num)
方案三：left join替換in
如SQL:SELECT id FROM A WHERE num in(select num from B)
優化成：SELECT id FROM A LEFT JOIN B ON A.num = B.num
8、where子句中對字段進行表達式操作的優化
不要在where子句中的“=”左邊進行函數、算數運算或其他表達式運算，否則系統將可能無法正確使用索引。
A:如SQL:SELECT id FROM A WHERE num/2 = 100
優化成：SELECT id FROM A WHERE num = 100*2
B:如SQL:SELECT id FROM A WHERE year(addate) <2016
優化成：SELECT id FROM A where addate<'2016-01-01'
9、任何地方都不要用SELECT *
select * from table ，用具體的字段列表替換"*"，不要返回用不到的字段
10、使用“臨時表”暫存中間結果
采用臨時表暫存中間結果好處：
（1）避免程序中多次掃描主表，減少程序執行“共享鎖”阻塞“更新鎖”，減少了阻塞，提高了並發性能。
（2）盡量使用表變量來代替臨時表。如果表變量包含大量數據，請注意索引非常有限（只有主鍵索引）。
（3）避免頻繁創建和刪除臨時表，以減少系統資源的浪費。
（4）盡量避免向客戶端返回大數據量，若數據量過大，應考慮相應需求是否合理。
11、limit分頁優化
總數據有500萬左右，以下例子
select * from wl_tagindex where byname='f' order by id limit 300000,10; 行時間是 3.21s
優化后：
select * from (
select id from wl_tagindex
where byname='f' order by id limit 300000,10
) a
left join wl_tagindex b on a.id=b.id
執行時間為 0.11s 速度明顯提升。
這里需要說明的是 這里用到的字段是 byname ,id 需要把這兩個字段做復合索引，否則的話效果提升不明顯。
12、批量插入優化
INSERT into person(name,age) values('A',14);
INSERT into person(name,age) values('B',15);
INSERT into person(name,age) values('C',16);
優化為：INSERT into person(name,age) values('A',14),('B',15),('C',16);
13、利用limit 1 、top 1 取得一行
有時要查詢一張表時，你知道只需要看一條記錄，你可能去查詢一條特殊的記錄。可以使用limit 1 或者 top 1 來終止數據庫索引繼續掃描整個表或索引。
如SQL：SELECT id FROM A LIKE 'abc%'
優化為：SELECT id FROM A LIKE 'abc%' limit 1
14、盡量不要使用 BY RAND()命令
BY RAND()是隨機顯示結果，這個函數可能會為表中每一個獨立的行執行BY RAND()命令，這個會消耗處理器的處理能力。
15、排序的索引問題
Mysql查詢只是用一個索引，因此如果where子句中已經使用了索引的話，那么order by中的列是不會使用索引的。
因此數據庫默認排序可以符合要求情況下不要使用排序操作；
盡量不要包含多個列的排序，如果需要最好給這些列創建復合索引。
16、盡量用 union all 替換 union
union和union all的差異主要是前者需要將兩個（或者多個）結果集合並后再進行唯一性過濾操作，這就會涉及到排序，增加大量的cpu運算，
加大資源消耗及延遲。所以當我們可以確認不可能出現重復結果集或者不在乎重復結果集的時候，盡量使用union all而不是union
17、Inner join 和 left join、right join、子查詢
第一：inner join內連接也叫等值連接是，left/rightjoin是外連接。
SELECT A.id,A.name,B.id,B.name FROM A LEFT JOIN B ON A.id =B.id;
SELECT A.id,A.name,B.id,B.name FROM A RIGHT JOIN ON B A.id= B.id;
SELECT A.id,A.name,B.id,B.name FROM A INNER JOIN ON A.id =B.id;
經過多方面的證實inner join性能比較快，因為inner join是等值連接，或許返回的行數比較少。但是我們要記得有些語句隱形的用到了等值連接，如：
SELECT A.id,A.name,B.id,B.name FROM A,B WHERE A.id = B.id;
推薦：能用inner join連接盡量使用inner join連接
第二：子查詢的性能又比外連接性能慢，盡量用外連接來替換子查詢。
第三：使用JOIN時候，應該用小的結果驅動大的結果（left join 左邊表結果盡量小，如果有條件應該放到左邊先處理，right join同理反向），同時盡量把牽涉到多表 聯合的查詢拆分多個query (多個表查詢效率低，容易鎖表和阻塞)。如：
Select * from A left join B on A.id=B.ref_id where A.id>10;
可以優化為：select * from (select * from A wehre id >10) T1 left join B on T1.id=B.ref_id;
18、exist和 in的使用場景
SELECT * from A WHERE id in (SELECT id from B)
SELECT * from A WHERE id EXISTS(SELECT 1 from B where A.id= B.id)
in是在內存 中遍歷比較， exist 需要查詢數據庫，所以當B的數據量比較大時，exists效率優於in.
in()只執行一次，把B表中的所有id字段緩存起來，之后檢查A表的id是否與B表中的id相等，如果id相等則將A表的記錄加入到結果集中，直到遍歷完A表的所有記錄。
In 操作的流程原理如同以下代碼
List resultSet={};
Array A=(select * from A);
Array B=(select id from B);
for(int i=0;i<A.length;i++) {
for(int j=0;j<B.length;j++) {
if(A[i].id==B[j].id) {
resultSet.add(A[i]);
break;
}
}
}
return resultSet;
可以看出，當B表數據較大時不適合使用in()，因為它會將B表數據全部遍歷一次
如：A表有10000條記錄，B表有1000000條記錄，那么最多有可能遍歷10000*1000000次，效率很差。
再如：A表有10000條記錄，B表有100條記錄，那么最多有可能遍歷10000*100次，遍歷次數大大減少，效率大大提升。
結論：in()適合B表比A表數據小的情況
exist()會執行A.length()次，執行過程如同以下代碼
List resultSet={};
Array A=(select * from A);
for(int i=0;i<A.length;i++) {
if(exists(A[i].id) { //執行select 1 from B where B.id=A.id是否有記錄返回
resultSet.add(A[i]);
}
}
return resultSet;
當B表比A表數據大時適合使用exists()，因為它沒有那么多遍歷操作，只需要再執行一次查詢就行。
如：A表有10000條記錄，B表有1000000條記錄，那么exists()會執行10000次去判斷A表中的id是否與B表中的id相等。
當B表比A表數據大時適合使用exists()，因為它沒有那么多遍歷操作，只需要再執行一次查詢就行。
如：A表有10000條記錄，B表有1000000條記錄，那么exists()會執行10000次去判斷A表中的id是否與B表中的id相等。
如：A表有10000條記錄，B表有100000000條記錄，那么exists()還是執行10000次，因為它只執行A.length次，可見B表數據越多，越適合exists()發揮效果。
再如：A表有10000條記錄，B表有100條記錄，那么exists()還是執行10000次，還不如使用in()遍歷10000*100次，因為in()是在內存里遍歷比較，而exists()需要查詢數據庫，
我們都知道查詢數據庫所消耗的性能更高，而內存比較很快。
結論：exists()適合B表比A表數據大的情況
當A表數據與B表數據一樣大時，in與exists效率差不多，可任選一個使用。
19、索引的合理運用
where子句及order by涉及的列盡量建索引，不一定要全部建索引，依業務情形而定。對於多條where子句都用到的列，建議建索引。索引並不是越多越好，
索引固然可以提高相應的select的效率，但同時也降低了insert及update 的效率。
20、先分頁再查詢
對於多張大數據量（這里幾百條就算大了）的表JOIN，要先分頁再JOIN，否則邏輯讀會很高，性能很差。
21、統計的時候盡量標明列
select count(*) from table；這樣不帶任何條件的count會引起全表掃描，並且沒有任何業務意義，是一定要杜絕的。
可以改為select count(id) from table。
22、列能使用數字型就不要用字符型
盡量使用數字型字段，若只含數值信息的字段盡量不要設計為字符型，這會降低查詢和連接的性能，並會增加存儲開銷。
23、列的類型盡量使用可變的varchar
盡可能的使用varchar代替char，因為首先變長字段存儲空間小，可以節省存儲空間，其次對於查詢來說，在一個相對較小的字段內搜索效率顯然要高些。
暫時先就這些了,后續有補充的在加上!