mysql-常規優化思路
作業系統優化
sysbench 工具
1.測試CPU效能
2.測試IO讀寫效能
3.測試事務效能
資料庫系統引數優化
1.使用 show processlist命令長時間檢視伺服器負載情況
2.開啟伺服器慢查詢開關
3.減少臨時表使用，可以EXPLAIN 語法檢視 extra 是否為 using temporary
@如果group by 的列沒有索引，會產生內部臨時表
@如果order by 與 group by為不同列時，或多表聯查時 order by,group by 包含的列不是第一張表的列，會產生外部臨時表
@如果distinct 與 order by 一起使用可能會產生臨時表
@如果用union合併查詢會用到臨時表
@如果表中資料過大，可能會把臨時錶轉存在磁碟上處理
資料表設計
1.表結構拆分，核心欄位與非核心欄位或長文字欄位最好拆出單一張表
2.欄位選取規則：整形->data,time->enum,char->varchar->text->blob
3.欄位長度設定,夠用就行杜絕浪費
4.儘量避免用NULL()，不利於索引查詢，要用特殊的位元組來標註，佔有磁碟空間較大。
索引設計，myisam與innodb預設使用B-tree索引
1.建議建立單個索引，避免建立組合索引
2.索引值，或主鍵值應儘量是連續增長的整型值，不是隨機值
3.要建立適當的索引物件，過多的索引會影響插入和更新速度，同時佔用記憶體
4.對於左字首不易區分的列，要分析資料內容找出最容易區別的部分放在前面，（比如，要url倒過來儲存，字尾都不一樣）
5.索引碎片維護，長期的資料更改過程中, 索引檔案和資料檔案,都將產生空洞,形成碎片
4.注意索引的左字首原則，範圍截斷原則(or 條件，只要其中一個沒有都不會用索引)
建立組合索引index(a,b,c) 為例：
|
語句 |
索引是否發揮作用 |
|
Where a=3 |
是,只使用了a列 |
|
Where a=3 and b=5 |
是,使用了a,b列 |
|
Where a=3 and b=5 and c=4 |
是,使用了abc |
|
Where b=3 or where c=4 |
否 |
|
Where a=3 and c=4 |
a列能發揮索引,c不能 |
|
Where a=3 and b>10 and c=7 |
a能利用,b能利用, c不能利用 |
|
同上,where a=3 and b like ‘xxxx%’ and c=7 |
a能用,b能用,c不能用 |
建立多個單列索引index(a),index(b),index(c)
|
語句 |
索引是否發揮作用 |
|
Where a=3 |
是,只使用了a列 |
|
Where a=3 and b=5 |
是,使用了a,b列 |
|
Where a=3 and b=5 and c=4 |
是,使用了abc |
|
Where b=3 or where c=4 |
bc使用 |
|
Where a=3 and c=4 |
ac都使用 |
|
Where a=3 and b>10 and c=7 |
a能利用,b能利用, c不能利用 |
|
同上,where a=3 and b like ‘xxxx%’ and c=7 |
a能用,b用,c不能用 |
sql語句優化
1.儘量使用索引覆蓋，加快查詢速度（查詢只需要在索引檔案上進行,不需要回行到磁碟再找資料）
2.在大資料範圍查詢時，儘量在索引覆蓋上面查詢到需要的索引id,然後在通過id去查到對應的資料
3.儘量減少查詢次數，能用業務邏輯處理的功能，都用演算法處理。
4.利用explain來利用分析
hash索引為什麼不能作為資料儲存原因：
1.hash函式計算後的結果,是隨機的,如果是在磁碟上放置資料,比主鍵為id為例, 那麼隨著id的增長, id對應的行,在磁碟上隨機放置
2.無法對範圍查詢進行優化
3.無法利用字首索引
4.排序無法優化
5.必須回行.就是說 通過索引拿到資料位置,必須回到表中取資料