記優化資料庫的經歷

一：針對where 條件 order by 字段優化（2014-10-22）

問題：只要加上order by 速度就很慢

介紹：乙個文章表，大小有1.6g，表結構是

id(主鍵遞增) nid(**書id) vid(**章節id) content(**內容) time(時間)

業務要求：搜尋出每本**的前12個最新章節

sql:

select id,name,content from table where nid=1024 order by time desc limit 12

優化經歷：

原本表中對nid這個欄位加個索引，時間快了一點，但是只要使用order by就頓時慢了，所以就要想辦法優化order by

對這塊的優化，最好是使用聯合索引，針對nid和time

alter table table add index nid_time_index(nid,time);

速度明顯上公升，問題解決

二：針對聯合查詢join order by limit優化（2014-10-23）

問題：表中400w+資料，left join聯合查詢，如果加上order by 後,速度慢很多

原始sql：

select * from t_people p left join t_team t on p.team_id=t.id order by p.pname limit 10;

優化：create index pnameindex on t_people (pname asc)

select * from (select * from t_people porder by p.pnamelimit 10) p left join t_team t on p.team_id=t.id limit 10;

參考：

總結：針對以上兩個優化經歷，可以得出結論是" mysql資料庫是先搜尋後排序 "，這樣時間就消耗的多了，因此優化就是先篩選出需要的資料，再去排序

三：1.謹慎使用text/blob型別

當列型別是text或者blob時，我們應該特別注意，因為當選擇的字段有 text/blob 型別的時候，無法建立記憶體表，只能建立硬碟臨時表，而硬碟臨時表的效能比記憶體表的效能差，所以如果非要使用text/blob型別，應該單獨建表，不要把text/blob型別與核心屬性混合在一張表中

2.慎用子查詢

幾乎所有子查詢都可以改寫為連線查詢，有時候，連線查詢的效率要比子查詢高，所以把子查詢改寫成連線查詢是乙個不錯的注意。如果一條使用子查詢的select語句執行時間過長，那麼就應該嘗試把它改寫為連線查詢，看他是不是執行的更好。

select*fromempwhereenamein(selectenamefromename);

selectemp.*fromempinnerjoinenameonemp.ename=ename.ename;

3.在distinct列上增加索引

4.在group by後面增加order by null

在使用group by分組查詢時，預設分組後，還會排序，可能會降低速度。如果不需要排序，那麼可以在group by後面增加order by null，這樣可以避免分組後排序