這篇文章主要介紹“優(yōu)化 | 重要的MySQL開發(fā)規(guī)范都在這了”,在日常操作中,相信很多人在優(yōu)化 | 重要的MySQL開發(fā)規(guī)范都在這了問題上存在疑惑,小編查閱了各式資料,整理出簡單好用的操作方法,希望對大家解答”優(yōu)化 | 重要的MySQL開發(fā)規(guī)范都在這了”的疑惑有所幫助!接下來,請跟著小編一起來學(xué)習(xí)吧!
成都創(chuàng)新互聯(lián)公司主營賓縣網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營網(wǎng)站建設(shè)方案,成都APP應(yīng)用開發(fā),賓縣h5小程序制作搭建,賓縣網(wǎng)站營銷推廣歡迎賓縣等地區(qū)企業(yè)咨詢
1、默認(rèn)使用InnoDB引擎
【老葉觀點(diǎn)】已多次呼吁過了,InnoDB適用于幾乎99%的MySQL應(yīng)用場景,而且在MySQL 5.7的系統(tǒng)表都改成InnoDB了,還有什么理由再死守MyISAM呢。
此外,頻繁讀寫的InnoDB表,一定要使用具有自增/順序特征的整型作為顯式主鍵。
2、字符集選擇utf-8
【老葉觀點(diǎn)】若為了節(jié)省磁盤空間,則建議選擇latin1。建議選擇utf-8通常是為了所謂的“通用性”,但事實(shí)上用戶提交的utf-8數(shù)據(jù)也一樣可以以latin1字符集存儲。
用latin1存儲utf-8數(shù)據(jù)可能遇到的麻煩是,如果有基于中文的檢索時,可能無法100%準(zhǔn)確(老葉親自簡單測試常規(guī)的中文完檢索全不是問題,也就是一般的中文對比是沒問題的)。
用latin1字符集存儲utf-8數(shù)據(jù)的做法是:在web端(用戶端)的字符集是utf-8,后端程序也采用utf-8來處理,但 character_set_client、character_set_connection、character_set_results、character_set_database、character_set_server 這幾個都是 latin1,且數(shù)據(jù)表、字段的字符集也是latin1。或者說數(shù)據(jù)表采用latin1,每次連接后執(zhí)行 SET NAMES LATIN1 即可。
3、InnoDB表行記錄物理長度不超過8KB
【老葉觀點(diǎn)】InnoDB的data page默認(rèn)是16KB,基于B+Tree的特點(diǎn),一個data page中需要至少存儲2條記錄。因此,當(dāng)實(shí)際存儲長度超過8KB(尤其是TEXT/BLOB列)的大列(large column)時會引起“page-overflow存儲”,類似ORACLE中的“行遷移”。
因此,如果必須使用大列(尤其是TEXT/BLOB類型)且讀寫頻繁的話,則最好把這些列拆分到子表中,不要和主表放在一起存儲。如果不太頻繁,可以考慮繼續(xù)保留在主表中。
當(dāng)然了,如果將 innodb_page_size 選項(xiàng)修改成 8KB,那么行記錄物理長度建議不超過4KB。
【參考】:[MySQL優(yōu)化案例]系列 — 優(yōu)化InnoDB表BLOB列的存儲效率。
4、是否使用分區(qū)表
【老葉觀點(diǎn)】在一些使用分區(qū)表后明顯可以提升性能或者運(yùn)維便利性的場景下,還是建議使用分區(qū)表。
比如老葉就在zabbix的數(shù)據(jù)庫采用TokuDB引擎的前提下,又根據(jù)時間維度使用了分區(qū)表。這樣的好處是保證zabbix日常應(yīng)用不受到影響前提下,方便管理員例行刪除過去數(shù)據(jù),只需要刪除相應(yīng)分區(qū)即可,不需再執(zhí)行一個非常慢的DELETE而影響整體性能。
參考:遷移Zabbix數(shù)據(jù)庫到TokuDB。
5、是否使用存儲過程、觸發(fā)器
【老葉觀點(diǎn)】在一些合適的場景下,用存儲過程、觸發(fā)器也完全沒問題。
我們以前就是利用存儲完成游戲業(yè)務(wù)邏輯處理,性能上不是問題,而且一旦需求有變更,只需修改存儲過程,變更代價很低。我們還利用觸發(fā)器維護(hù)一個頻繁更新的表,對這個表的所有變更都將部分字段同步更新到另一個表中(類似物化視圖的變相實(shí)現(xiàn)),也不存在性能問題。
不要把MySQL的存儲過程和觸發(fā)器視為洪水猛獸,用好的話,沒有問題的,真遇到問題了再優(yōu)化也不遲。另外,MySQL因?yàn)闆]有物化視圖,因此視圖能不用就盡量少用吧。
6、選擇合適的類型
【老葉觀點(diǎn)】除了常見的建議外,還有其他幾個要點(diǎn):
6.1、用INT UNSIGNED存儲IPV4地址,用INET_ATON()、INET_NTOA()進(jìn)行轉(zhuǎn)換,基本上沒必要使用CHAR(15)來存儲。
6.2、枚舉類型可以使用ENUM,ENUM的內(nèi)部存儲機(jī)制是采用TINYINT或SMALLINT(并非CHAR/VARCHAR),性能一點(diǎn)都不差,記住千萬別用CHAR/VARCHAR 來存儲枚舉數(shù)據(jù)。
6.3、還個早前一直在傳播的“常識性誤導(dǎo)”,建議用TIMESTAMP取代DATETIME。其實(shí)從5.6開始,建議優(yōu)先選擇DATETIME存儲日期時間,因?yàn)樗目捎梅秶萒IMESTAMP更大,物理存儲上僅比TIMESTAMP多1個字節(jié),整體性能上的損失并不大。
6.4、所有字段定義中,默認(rèn)都加上NOT NULL約束,除非必須為NULL(但我也想不出來什么場景下必須要在數(shù)據(jù)庫中存儲NULL值,可以用0來表示)。在對該字段進(jìn)行COUNT()統(tǒng)計(jì)時,統(tǒng)計(jì)結(jié)果更準(zhǔn)確(值為NULL的不會被COUNT統(tǒng)計(jì)進(jìn)去),或者執(zhí)行 WHERE column IS NULL 檢索時,也可以快速返回結(jié)果。
6.5、盡可能不要直接 SELECT * 讀取全部字段,尤其是表中存在 TEXT/BLOB 大列的時候。可能本來不需要讀取這些列,但因?yàn)橥祽袑懗?SELECT * 導(dǎo)致內(nèi)存buffer pool被這些“垃圾”數(shù)據(jù)把真正需要緩沖起來的熱點(diǎn)數(shù)據(jù)給洗出去了。
8、關(guān)于索引
【老葉觀點(diǎn)】除了常見的建議外,還有幾個要點(diǎn):
8.1、超過20個長度的字符串列,最好創(chuàng)建前綴索引而非整列索引(例如:ALTER TABLE t1 ADD INDEX(user(20))),可以有效提高索引利用率,不過它的缺點(diǎn)是對這個列排序時用不到前綴索引。前綴索引的長度可以基于對該字段的統(tǒng)計(jì)得出,一般略大于平均長度一點(diǎn)就可以了。
8.2、定期用 pt-duplicate-key-checker 工具檢查并刪除重復(fù)的索引。比如 index idx1(a, b) 索引已經(jīng)涵蓋了 index idx2(a),就可以刪除 idx2 索引了。
8.3、有多字段聯(lián)合索引時,WHERE中過濾條件的字段順序無需和索引一致,但如果有排序、分組則就必須一致了。
比如有聯(lián)合索引 idx1(a, b, c),那么下面的SQL都可以完整用到索引:
[MySQL FAQ]系列 — 從MyISAM轉(zhuǎn)到InnoDB需要注意什么
[MySQL FAQ]系列 — 為什么InnoDB表要建議用自增列做主鍵
小談MySQL字符集
[MySQL優(yōu)化案例]系列 — 優(yōu)化InnoDB表BLOB列的存儲效率
遷移Zabbix數(shù)據(jù)庫到TokuDB
[MySQL優(yōu)化案例]系列 — 分頁優(yōu)化
[MySQL優(yōu)化案例]系列 — RAND()優(yōu)化
[MySQL FAQ]系列 — 什么情況下會用到臨時表
[MySQL FAQ]系列 — EXPLAIN結(jié)果中哪些信息要引起關(guān)注
到此,關(guān)于“優(yōu)化 | 重要的MySQL開發(fā)規(guī)范都在這了”的學(xué)習(xí)就結(jié)束了,希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí),快去試試吧!若想繼續(xù)學(xué)習(xí)更多相關(guān)知識,請繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站,小編會繼續(xù)努力為大家?guī)砀鄬?shí)用的文章!
新聞名稱:優(yōu)化|重要的MySQL開發(fā)規(guī)范都在這了
網(wǎng)站網(wǎng)址:http://www.chinadenli.net/article40/jigceo.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供全網(wǎng)營銷推廣、定制開發(fā)、網(wǎng)頁設(shè)計(jì)公司、Google、電子商務(wù)、網(wǎng)站改版
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)