Mysql優(yōu)化思路
- 來(lái)源:縱橫數(shù)據(jù)
- 作者:中橫科技
- 時(shí)間:2020/4/28 15:18:37
- 類(lèi)別:新聞資訊
首先構(gòu)建腳本觀察查詢(xún)數(shù),連接數(shù)等數(shù)據(jù),確定環(huán)境原因以及內(nèi)部SQL執(zhí)行原因,然后根據(jù)具體原因做具體處理。
二、構(gòu)建腳本觀察狀態(tài)
1 |
|
該命令可獲取當(dāng)前查詢(xún)數(shù)量等信息,定時(shí)輪詢(xún)并將結(jié)果重定向到文本中,然后處理成圖表。
三、處理對(duì)策
1.若是規(guī)律性出現(xiàn)查詢(xún)慢,考慮緩存雪崩問(wèn)題。
對(duì)于該問(wèn)題只需將緩存的失效時(shí)間處理成不要相近時(shí)間同時(shí)失效,失效時(shí)間盡量離散化,或者集中到午夜失效。
2.若非規(guī)律性查詢(xún)緩慢,考慮設(shè)計(jì)缺乏優(yōu)化
處理方法:
a:開(kāi)啟profiling記錄查詢(xún)操作,并獲取語(yǔ)句執(zhí)行詳細(xì)信息
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
|
b:使用explain 查看語(yǔ)句執(zhí)行情況,索引使用,掃描范圍等等
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
c:相關(guān)優(yōu)化手法
表的優(yōu)化與列類(lèi)型選擇
列選擇原則:
1:字段類(lèi)型優(yōu)先級(jí) 整型 > date,time > char,varchar > blob
原因:整型,time運(yùn)算快,節(jié)省空間
char/varchar要考慮字符集的轉(zhuǎn)換與排序時(shí)的校對(duì)集,速度慢
blob無(wú)法使用內(nèi)存臨時(shí)表
2:夠用就行,不要慷慨(如 smallint,varchar(N))
原因:大的字段浪費(fèi)內(nèi)存,影響速度
以varchar(10), varchar(300)存儲(chǔ)的內(nèi)容相同,但在表聯(lián)查時(shí),varchar(300)要花更多內(nèi)存
3:盡量避免使用NULL
原因:NULL不利于索引,要用特殊的字節(jié)來(lái)標(biāo)注.
在磁盤(pán)上占據(jù)的空間其實(shí)更大
索引優(yōu)化策略
1.索引類(lèi)型
1.1 B-tree索引(排好序的快速查找結(jié)構(gòu))
注:Myisam,innodb中,默認(rèn)用的是B-tree索引
1.2 hash索引
在memory表里,默認(rèn)是hash索引,hash的理論查詢(xún)時(shí)間復(fù)查度為O(1)
疑問(wèn):既然hash索引如此高效,為何不都用他?
a.hash函數(shù)計(jì)算后的結(jié)果是隨機(jī)的,如果是在磁盤(pán)上放置數(shù)據(jù),以主鍵為id為例,那么隨著id的增長(zhǎng),id對(duì)應(yīng)的行,在磁盤(pán)上隨機(jī)放置。
b.無(wú)法對(duì)范圍查詢(xún)進(jìn)行優(yōu)化
c.無(wú)法利用前綴索引,比如在b-tree中,field列的值為“helloworld”,索引查詢(xún)xx=hello/xx=helloworld都可以利用索引(左前綴索引),但hash索引無(wú)法做到,因?yàn)閔ash(hello)與hash(helloworld)并無(wú)關(guān)聯(lián)關(guān)系。
d.排序也無(wú)法優(yōu)化
e.必須回行,通過(guò)索引拿到數(shù)據(jù)位置,必須回到表中取數(shù)據(jù).
2.b-tree索引的常見(jiàn)誤區(qū)
2.1 在where條件常用的列上都加上索引
例:where cat_id=3 and price>100; //查詢(xún)第3個(gè)欄目,100元以上的商品
誤:cat_id和price上都加上索引。其實(shí)只能用上一個(gè)索引,他們都是獨(dú)立索引.
2.2 在多列上建立索引后,查詢(xún)哪個(gè)列,索引都將發(fā)揮作用
2.2 在多列上建立索引后,查詢(xún)哪個(gè)列,索引都將發(fā)揮作用
正解:多列索引上,索引發(fā)揮作用,需要滿(mǎn)足左前綴要求(層層索引)
以index(a,b,c)為例:
1 2 3 4 5 6 7 |
|
高性能索引策略
1.對(duì)于innodb而言,因?yàn)楣?jié)點(diǎn)下有數(shù)據(jù)文件,因此節(jié)點(diǎn)的分裂將會(huì)變得比較慢,對(duì)于innodb的主鍵,盡量用整型,而且是遞增的整型。
2.索引的長(zhǎng)度直接影響索引文件的大小,影響增刪改的速度,并間接影響查詢(xún)速度(占用內(nèi)存多)。
3.針對(duì)列中的值,從左往右截取部分來(lái)建索引。
a.截的越短,重復(fù)度越高,區(qū)分越小,索引效果越不好
b.截的越長(zhǎng),雖然區(qū)分度提高,但索引文件變大影響速度
所以盡量在長(zhǎng)度上找到一個(gè)平衡點(diǎn)使性能最大化,慣用手法:截取不同長(zhǎng)度來(lái)測(cè)試索引區(qū)分度
區(qū)分度測(cè)試:
1 |
|
測(cè)試完成后可以按測(cè)試得出的最優(yōu)長(zhǎng)度建立索引
1 |
|
理想的索引
1.查詢(xún)頻繁
2.區(qū)分度高
3.長(zhǎng)度小
4.盡量覆蓋常用查詢(xún)字段
縱橫數(shù)據(jù)新上的美國(guó)站群服務(wù)器8C 現(xiàn)貨
限量特價(jià) 速定! cn2限量一人3臺(tái)
E5 16G 1T 8C 232IP
E5*2 32G 1T 8C 232IP
E5*2 32G 2T 8C 232IP
E5*2 32G 3T 8C 232IP
美國(guó)站群服務(wù)器 美國(guó)高防御服務(wù)器 歡迎在線(xiàn)客服