MySQL調(diào)優(yōu) 優(yōu)化需要考慮哪些方面
優(yōu)化目標(biāo)與方向定位
可優(yōu)化維度
設(shè)計(jì)優(yōu)化
- 選擇適合的DBMS
- 對(duì)表恰當(dāng)?shù)脑O(shè)計(jì)
- 盡量遵循第三范式。減少冗余的同時(shí)減少增刪改時(shí)出錯(cuò)的可能。
- 適當(dāng)?shù)?反范式"，以空間換時(shí)間，提高多表聯(lián)查的效率。
- 選擇恰當(dāng)?shù)淖侄晤愋汀１M量選擇數(shù)據(jù)類型，盡量選擇字符長(zhǎng)度小的字符類型。
查詢優(yōu)化
- 對(duì)SQL查詢進(jìn)行邏輯優(yōu)化 --- 就是使用恰當(dāng)?shù)腟QL語(yǔ)句讓查詢速度更快
- 比如“小表驅(qū)動(dòng)大表”的EXISTS和IN
- 比如子查詢優(yōu)化，簡(jiǎn)化查詢條件等等
- 對(duì)SQL查詢進(jìn)行物理優(yōu)化 --- 就是通過索引或表鏈接的方式進(jìn)行優(yōu)化，本質(zhì)上是對(duì)Server層優(yōu)化器和執(zhí)行器進(jìn)行“人工輔助”，人為地減輕優(yōu)化器和執(zhí)行器的壓力。
- 索引
- 為表設(shè)計(jì)精簡(jiǎn)且高效的索引 --- 索引不是越多越好，索引需要占據(jù)存儲(chǔ)空間，過多的索引也會(huì)提高優(yōu)化器選擇索引的難度。比如字段內(nèi)數(shù)據(jù)重復(fù)度高時(shí)不建立索引，如性別
- 若在where中對(duì)索引字段進(jìn)行了表達(dá)式計(jì)算，會(huì)造成該字段索引失效。
- 設(shè)計(jì)聯(lián)合索引時(shí)選擇恰當(dāng)?shù)捻樞?--- 最左前綴原則
- 表連接
- 單表：全表掃描或局部掃描
- 兩表：合并連接，HASH連接，嵌套循環(huán)連接
- 多表：連接順序
外置緩存
數(shù)據(jù)都是存放在數(shù)據(jù)庫(kù)（磁盤）中的，在有使用需要的時(shí)候就會(huì)將磁盤數(shù)據(jù)調(diào)入內(nèi)存。但當(dāng)用戶量增大時(shí)，使用大量數(shù)據(jù)，頻繁讀取磁盤會(huì)消耗大量資源。因此我們可以事先將常用的數(shù)據(jù)放入內(nèi)存中來(lái)提高查詢效率。
- 鍵值存儲(chǔ)數(shù)據(jù)庫(kù) Redis 和 Memcached 等
- Redis 支持持久化且支持的數(shù)據(jù)類型和數(shù)據(jù)結(jié)構(gòu)比Memcached多。Memcached僅進(jìn)行內(nèi)存存儲(chǔ)且僅支持鍵值對(duì)存儲(chǔ)。
- 對(duì)于查詢響應(yīng)要求高的場(chǎng)景可以考慮上述內(nèi)存數(shù)據(jù)庫(kù)，不過增加的開發(fā)人員的工作量。
庫(kù)級(jí)優(yōu)化
一般來(lái)說(shuō)現(xiàn)在常見的關(guān)系型數(shù)據(jù)庫(kù)單表可以存儲(chǔ)億級(jí)的數(shù)據(jù)量。
當(dāng)數(shù)據(jù)量達(dá)到億級(jí)以上時(shí)可以采用以下方案進(jìn)行庫(kù)級(jí)優(yōu)化。
- 讀寫分離：使用主從數(shù)據(jù)庫(kù)代替單一數(shù)據(jù)庫(kù)，降低單一數(shù)據(jù)庫(kù)時(shí)的負(fù)載。主庫(kù)完成寫操作，從庫(kù)完成讀操作。
- 分庫(kù)分表
- 垂直切分
- 垂直分庫(kù)：數(shù)據(jù)表過多時(shí)，對(duì)表進(jìn)行劃分，將相關(guān)聯(lián)的數(shù)據(jù)表存放在一個(gè)庫(kù)中
- 垂直分表：數(shù)據(jù)表列較多時(shí)，對(duì)列進(jìn)行劃分并拆分成多個(gè)表，將經(jīng)常一起使用的列存入一張表中
- 水平切分
- 表中數(shù)據(jù)量達(dá)到億級(jí)以上時(shí)，在保持相同的表結(jié)構(gòu)的情況下，將表按照某一屬性拆分成不同小表。
- 分庫(kù)分表也會(huì)增加維護(hù)和使用成本，要加以平衡。
|
