MySQL是一種開(kāi)放源代碼的關(guān)系型數(shù)據(jù)庫(kù)管理系統(tǒng)（RDBMS），MySQL作為目前系統(tǒng)開(kāi)發(fā)中最常用的數(shù)據(jù)庫(kù)之一，因?yàn)槠渌俣取⒖煽啃院瓦m應(yīng)性而備受開(kāi)發(fā)者的青睞。然而為了避免我們?cè)贛ySQL數(shù)據(jù)庫(kù)開(kāi)發(fā)中遭遇致命的錯(cuò)誤，我們需要恪守MySQL數(shù)據(jù)庫(kù)開(kāi)發(fā)核心原則。以下所列出的5條MySQL數(shù)據(jù)庫(kù)開(kāi)發(fā)核心原則是所有MySQL數(shù)據(jù)庫(kù)開(kāi)發(fā)時(shí)應(yīng)該遵守的。希望可以引起重視。

1.盡量避免在數(shù)據(jù)庫(kù)中做運(yùn)算

“使雞司夜,令貍執(zhí)鼠,皆用其能,上乃無(wú)事。”古人都早已參透各司其職，各盡其責(zé)的重要性，作為現(xiàn)代化的數(shù)據(jù)庫(kù)開(kāi)發(fā)人員，我們更應(yīng)該讓數(shù)據(jù)庫(kù)做其本職工作，而不是”物盡其用”。所以，我們應(yīng)該盡量避免在數(shù)據(jù)庫(kù)中做一些運(yùn)算，復(fù)雜運(yùn)算轉(zhuǎn)移到程序端CPU，那里才是它的戰(zhàn)場(chǎng)。我們應(yīng)該避免在數(shù)據(jù)庫(kù)中使用復(fù)雜的運(yùn)算函數(shù)，畢竟術(shù)業(yè)有專攻，這不是數(shù)據(jù)庫(kù)的強(qiáng)項(xiàng)，處理復(fù)雜運(yùn)算的任務(wù)就交給CPU好了。

2.盡量控制表字段數(shù)量

單表的字段數(shù)量不能太多，否則會(huì)影響數(shù)據(jù)庫(kù)的優(yōu)化。根據(jù)業(yè)務(wù)場(chǎng)景進(jìn)行優(yōu)化調(diào)整，盡量調(diào)整表字段數(shù)少而精，這樣可以使得IO高效，能夠快速的遍歷全表，二區(qū)還能提高數(shù)據(jù)庫(kù)的并發(fā)性。

通過(guò)特定標(biāo)準(zhǔn)來(lái)控制字段數(shù)量，按照單表1G體積，500W行數(shù)據(jù)量進(jìn)行評(píng)估：順序讀1G文件需N秒，單行不超過(guò)200Byte，單表不超50個(gè)純INT字段，單表不超20個(gè)CHAR(10)字段，建議單表字段數(shù)上限控制在20~50個(gè)。

3.平衡范式與冗余

數(shù)據(jù)庫(kù)表結(jié)構(gòu)的設(shè)計(jì)也講究平衡，以往我們經(jīng)常說(shuō)要嚴(yán)格遵循三大范式，所以先來(lái)說(shuō)說(shuō)什么是范式。第一范式：?jiǎn)蝹€(gè)字段不可再分。唯一性。第二范式：不存在非主屬性只依賴部分主鍵。消除不完全依賴。第三范式：消除傳遞依賴。用一句話來(lái)總結(jié)范式和冗余：冗余是以存儲(chǔ)換取性能，范式是以性能換取存儲(chǔ)。所以，一般在實(shí)際工作中冗余更受歡迎一些。模型設(shè)計(jì)時(shí)，這兩方面的具體的權(quán)衡，首先要以企業(yè)提供的計(jì)算能力和存儲(chǔ)資源為基礎(chǔ)。其次，一般互聯(lián)網(wǎng)行業(yè)中都根據(jù)Kimball模式實(shí)施數(shù)據(jù)倉(cāng)庫(kù)，建模也是以任務(wù)驅(qū)動(dòng)的，因此冗余和范式的權(quán)衡符合任務(wù)需要。例如，一份指標(biāo)數(shù)據(jù)，必須在早上8點(diǎn)之前處理完成，但計(jì)算的時(shí)間窗口又很小，要盡可能減少指標(biāo)的計(jì)算耗時(shí)，這時(shí)在計(jì)算過(guò)程中要盡可能減少多表關(guān)聯(lián)，模型設(shè)計(jì)時(shí)需要做更多的冗余。

4.拒絕三個(gè)B

由于數(shù)據(jù)庫(kù)的并發(fā)就像城市交通，呈非線性增長(zhǎng)，這就要求我們?cè)谧鰯?shù)據(jù)庫(kù)開(kāi)發(fā)的時(shí)候一定要注意高并發(fā)下的瓶頸，防止因高并發(fā)造成數(shù)據(jù)庫(kù)癱瘓。

這里的3B是指：

大SQL（BIG SQL）：要減少

大事務(wù)（BIG Transaction）

大批量（BIG Batch）

5.盡量控制單表數(shù)據(jù)量

大家都知道單表數(shù)據(jù)量過(guò)大后會(huì)影響數(shù)據(jù)查詢效率，嚴(yán)重情況下會(huì)導(dǎo)致整個(gè)庫(kù)都卡住。一般情況下，按照一年內(nèi)單表數(shù)據(jù)量預(yù)估：純INT不超過(guò)1000W，含CHAR不超過(guò)500W，同時(shí)要盡量做好合理的分表，使單表數(shù)據(jù)量不超載，常見(jiàn)的分表策略有：通過(guò)USERID來(lái)分表（根據(jù)ID區(qū)間分表）：在金融行業(yè)應(yīng)用較多，用戶量大、用戶特征明顯。按DATE分表（按天、周、月分表）：在電信行業(yè)應(yīng)用非常多，如用戶上網(wǎng)記錄表、用戶短信表、話單表等。按AREA分表（省、市、區(qū)分表）。

實(shí)際上，這些MySQL數(shù)據(jù)庫(kù)開(kāi)發(fā)的核心原則或者說(shuō)MySQL數(shù)據(jù)庫(kù)開(kāi)發(fā)的注意事項(xiàng)在網(wǎng)上有很多大同小異的版本，其實(shí)主要還是前輩用引以為鑒的歷史事件得出的寶貴的經(jīng)驗(yàn)教訓(xùn)。準(zhǔn)確的來(lái)說(shuō)，這些原則就是MySQL數(shù)據(jù)庫(kù)開(kāi)發(fā)的紅線，一旦觸及，可能會(huì)發(fā)生意想不到的后果。所以，小伙伴們請(qǐng)謹(jǐn)記這些MySQL數(shù)據(jù)庫(kù)開(kāi)發(fā)的核心原則，使得我們的MySQL數(shù)據(jù)庫(kù)開(kāi)發(fā)更加合理更加規(guī)范。在后面的MySQL教程中，對(duì)這些原則有很好的講解。