前言

目前大部分公司的數(shù)據(jù)庫(kù)都是MySQL，雖然現(xiàn)在NoSQL數(shù)據(jù)庫(kù)比如mongo, hbase越來(lái)越流行了，但傳統(tǒng)的MySQL依然是業(yè)界用得最多。本文是以MySQL為例。

數(shù)據(jù)庫(kù)

數(shù)據(jù)庫(kù)是唯一在應(yīng)用系統(tǒng)中的單點(diǎn)資源，對(duì)于數(shù)據(jù)庫(kù)的資源的使用要特別小心。有如下幾點(diǎn)注意點(diǎn)

數(shù)據(jù)庫(kù)作為數(shù)據(jù)存儲(chǔ)的地方，不應(yīng)該把寶貴的資源用于數(shù)據(jù)的轉(zhuǎn)換或統(tǒng)計(jì)操作，SQL中不使用一些字符轉(zhuǎn)換等操作。

數(shù)據(jù)庫(kù)連接資源寶貴，外圍系統(tǒng)按需繼續(xù)分配使用

數(shù)據(jù)庫(kù)不怕高qps的小查詢，但害怕慢查詢，因此請(qǐng)消滅慢查詢。

索引不是越多越好，維護(hù)索引資源也耗費(fèi)數(shù)據(jù)庫(kù)運(yùn)算資源

數(shù)據(jù)庫(kù)運(yùn)算能力寶貴程度大于存儲(chǔ)

如果是主從架構(gòu)，主機(jī)器與從機(jī)器的網(wǎng)絡(luò)帶寬及穩(wěn)定性要保證

不在數(shù)據(jù)庫(kù)中存儲(chǔ)圖片、文件等大數(shù)據(jù)

禁止在線上做數(shù)據(jù)庫(kù)壓力測(cè)試

禁止從測(cè)試、開(kāi)發(fā)環(huán)境直連線上數(shù)據(jù)庫(kù)

不在業(yè)務(wù)高峰期批量更新、查詢數(shù)據(jù)庫(kù)

不在MySQL數(shù)據(jù)庫(kù)中存放業(yè)務(wù)邏輯,寫(xiě)儲(chǔ)存過(guò)程及觸發(fā)器等

禁止在主庫(kù)上執(zhí)行后臺(tái)管理和統(tǒng)計(jì)報(bào)表類的功能查詢，都放到從庫(kù)

硬件

磁盤(pán)
MySQL每秒鐘都在進(jìn)行大量、復(fù)雜的查詢操作，對(duì)磁盤(pán)的讀寫(xiě)量可想而知。所以，通常認(rèn)為磁盤(pán)I/O是制約MySQL性能的最大因素之一，推薦使用RAID-0+1磁盤(pán)陣列。

CPU
推薦使用至少4U以上的服務(wù)器來(lái)專門(mén)做數(shù)據(jù)庫(kù)服務(wù)器，基本上是越多越好

內(nèi)存
服務(wù)器內(nèi)存建議不要小于4GB。基本上是越大越好
系統(tǒng)配置
MySQL配置在my.conf,影響新能的幾個(gè)關(guān)鍵配置屬性

• 使用INNODB存儲(chǔ)引擎 5.5以后的默認(rèn)引擘，支持事務(wù)，行級(jí)鎖，更好的恢復(fù)性，高并發(fā)下性能更好，對(duì)多核，大內(nèi)存，ssd等硬件支持更好。
• 表字符集使用utf8mb4 使用utf8mb4字符集，如果是漢字，占3個(gè)字節(jié)，但ASCII碼字符還是1個(gè)字節(jié)；統(tǒng)一，不會(huì)有轉(zhuǎn)換產(chǎn)生亂碼風(fēng)險(xiǎn)，并能解決符號(hào)表情亂碼問(wèn)題；
• max_connections 最大連接（用戶）數(shù)
• innodb_log_file_size 在高寫(xiě)入負(fù)載尤其是大數(shù)據(jù)集的情況下很重要。這個(gè)值越大則性能相對(duì)越高，但是要注意到可能會(huì)增加恢復(fù)時(shí)間。設(shè)置為 64-512MB，根據(jù)服務(wù)器大小而異
• Innodb_buffer_pool_pages_data 分配出去， 正在被使用頁(yè)的數(shù)量
• Innodb_buffer_pool_pages_total 緩沖區(qū)總共的頁(yè)面數(shù)
• Innodb_page_size 編譯的InnoDB頁(yè)大小(默認(rèn)16KB)

調(diào)優(yōu)參考計(jì)算方法：
val = Innodb_buffer_pool_pages_data / Innodb_buffer_pool_pages_total * 100%
val > 95% 則考慮增大 innodb_buffer_pool_size， 建議使用物理內(nèi)存的75%
val < 95% 則考慮減小 innodb_buffer_pool_size， 建議設(shè)置為：Innodb_buffer_pool_pages_data * Innodb_page_size * 1.05 / (102410241024)

查看數(shù)據(jù)庫(kù)配置及狀態(tài)
查詢innodb配置
show global variables where variable_name like ‘%innodb%’

查詢線程Cache配置
show variables like ‘thread_cache_size’;

查詢連接配置
show variables like ‘%connect%’;

查詢當(dāng)前狀態(tài)
status

show global status like ‘Thread%’;

數(shù)據(jù)庫(kù)表結(jié)構(gòu)

表結(jié)構(gòu)的設(shè)計(jì)目標(biāo)除了滿足業(yè)務(wù)以外，盡量減少代碼實(shí)現(xiàn)上的聯(lián)表查詢操作，因此在設(shè)計(jì)上可以適當(dāng)有一些冗余字段的設(shè)計(jì)，減少數(shù)據(jù)庫(kù)IO次數(shù)。
現(xiàn)在很流行的ElasticSearch等大數(shù)據(jù)存儲(chǔ)寬表的概念也是這種思想的體現(xiàn)

盡量避免使用分區(qū)表 MySQL的分區(qū)表實(shí)際性能不是很好。

拆分大字段和訪問(wèn)頻率低的字段，分離冷熱數(shù)據(jù)

采用合理的分庫(kù)分表策略，推薦使用HASH進(jìn)行分表，表名后綴使用十進(jìn)制數(shù)，下標(biāo)從0開(kāi)始首次分表盡量多的分，避免二次分表，二次分表的難度和成本較高

單表字段數(shù)控制在20個(gè)以內(nèi)

一條完整的建表語(yǔ)句中應(yīng)包含必要的字段、主鍵、合理的索引（綜合代碼中所有的條件語(yǔ)句創(chuàng)建合理的索引，主鍵必須要有
索引設(shè)計(jì)
索引是一把雙刃劍，它可以提高查詢效率但也會(huì)降低插入和更新的速度并占用磁盤(pán)空間。

單張表中索引數(shù)量不超過(guò)5個(gè)

單個(gè)索引中的字段數(shù)不超過(guò)5個(gè)

對(duì)字符串使用前綴索引，前綴索引長(zhǎng)度不超過(guò)10個(gè)字符；如果有一個(gè)CHAR(200)列，如果在前10個(gè)字符內(nèi)，多數(shù)值是惟一的，那么就不要對(duì)整個(gè)列進(jìn)行索引。對(duì)前10個(gè)字符進(jìn)行索引能夠節(jié)省大量索引空間，也可能會(huì)使查詢更快

表必須有主鍵，不使用UUID、MD5、HASH作為主鍵，盡量不選擇字符串列作為主鍵；主鍵建議選擇自增id

創(chuàng)建復(fù)合索引時(shí)區(qū)分度較大的字段放在最前面；不在低區(qū)分度的字段上創(chuàng)建索引，如“性別”

避免冗余或重復(fù)索引

合理創(chuàng)建聯(lián)合索引（避免冗余），index(a、b、c) 相當(dāng)于index(a)、index(a、b)、index(a、、b、c)

索引不是越多越好，按實(shí)際需要進(jìn)行創(chuàng)建

每個(gè)額外的索引都要占用額外的磁盤(pán)空間，并降低寫(xiě)操作的性能

不在索引列進(jìn)行數(shù)學(xué)運(yùn)算和函數(shù)運(yùn)算；

盡量不要使用外鍵 外鍵用來(lái)保護(hù)參照完整性，可在業(yè)務(wù)端實(shí)現(xiàn)，對(duì)父表和子表的操作會(huì)相互影響，降低可用性；

不使用%前導(dǎo)的查詢，如like“%xxx”，不使用反向查詢，如not in / not like 無(wú)法使用索引，導(dǎo)致全表掃描 全表掃描導(dǎo)致buffer pool利用降低

字段設(shè)計(jì)

盡可能不要使用TEXT、BLOB類型。刪除這種值會(huì)在數(shù)據(jù)表中留下很大的"空洞"，可以考慮把BLOB或TEXT列分離到單獨(dú)的表中

用DECIMAL代替FLOAT和DOUBLE存儲(chǔ)精確浮點(diǎn)數(shù)。浮點(diǎn)數(shù)相對(duì)于定點(diǎn)數(shù)的優(yōu)點(diǎn)是在長(zhǎng)度一定的情況下，浮點(diǎn)數(shù)能夠表示更大的數(shù)據(jù)范圍；浮點(diǎn)數(shù)的缺點(diǎn)是會(huì)引起精度問(wèn)題

將字符轉(zhuǎn)化為數(shù)字

使用TINYINT來(lái)代替ENUM類型

字段長(zhǎng)度盡量按實(shí)際需要進(jìn)行分配，不要隨意分配一個(gè)很大的容量 VARCHAR(N)，N表示的是字符數(shù)不是字節(jié)數(shù)，比如VARCHAR(255)，可以最大可存儲(chǔ)255個(gè)漢字，需要根據(jù)實(shí)際的寬度來(lái)選擇N。VARCHAR(N)，N盡可能小，因?yàn)镸ySQL一個(gè)表中所有的VARCHAR字段最大長(zhǎng)度是65535個(gè)字節(jié)，進(jìn)行排序和創(chuàng)建臨時(shí)表一類的內(nèi)存操作時(shí)，會(huì)使用N的長(zhǎng)度申請(qǐng)內(nèi)存；

如果可能, 所有字段均定義為not null

使用UNSIGNED存儲(chǔ)非負(fù)整數(shù) 同樣的字節(jié)數(shù)，存儲(chǔ)的數(shù)值范圍更大。如tinyint有符號(hào)為-128-127，無(wú)符號(hào)為0-255

使用TIMESTAMP存儲(chǔ)時(shí)間. 因?yàn)門(mén)IMESTAMP使用4字節(jié)，DATETIME使用8個(gè)字節(jié),同時(shí)TIMESTAMP具有自動(dòng)賦值以及自動(dòng)更新的特性.

使用INT UNSIGNED存儲(chǔ)IPV4

使用VARBINARY存儲(chǔ)大小寫(xiě)敏感的變長(zhǎng)字符串

禁止在數(shù)據(jù)庫(kù)中存儲(chǔ)明文密碼

總結(jié)

以上是生活随笔為你收集整理的系统优化怎么做-数据库优化的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。