新聞中心
一、基礎規(guī)范
在密云等地區(qū),都構建了全面的區(qū)域性戰(zhàn)略布局,加強發(fā)展的系統(tǒng)性、市場前瞻性、產(chǎn)品創(chuàng)新能力,以專注、極致的服務理念,為客戶提供網(wǎng)站建設、網(wǎng)站設計 網(wǎng)站設計制作按需網(wǎng)站策劃,公司網(wǎng)站建設,企業(yè)網(wǎng)站建設,成都品牌網(wǎng)站建設,全網(wǎng)整合營銷推廣,成都外貿(mào)網(wǎng)站建設公司,密云網(wǎng)站建設費用合理。
表存儲引擎必須使用InnoDB
表字符集默認使用utf8,必要時候使用utf8mb4
解讀:
(1)通用,無亂碼風險,漢字3字節(jié),英文1字節(jié)
(2)utf8mb4是utf8的超集,有存儲4字節(jié)例如表情符號時,使用它
禁止使用存儲過程,視圖,觸發(fā)器,Event
解讀:
(1)對數(shù)據(jù)庫性能影響較大,互聯(lián)網(wǎng)業(yè)務,能讓站點層和服務層干的事情,不要交到數(shù)據(jù)庫層
(2)調試,排錯,遷移都比較困難,擴展性較差
禁止在數(shù)據(jù)庫中存儲大文件,例如照片,可以將大文件存儲在對象存儲系統(tǒng),數(shù)據(jù)庫中存儲路徑
禁止在線上環(huán)境做數(shù)據(jù)庫壓力測試
測試,開發(fā),線上數(shù)據(jù)庫環(huán)境必須隔離
二、命名規(guī)范
庫名,表名,列名必須用小寫,采用下劃線分隔
解讀:abc,Abc,ABC都是給自己埋坑
庫名,表名,列名必須見名知義,長度不要超過32字符
解讀:tmp,wushan誰TM知道這些庫是干嘛的
庫備份必須以bak為前綴,以日期為后綴
從庫必須以-s為后綴
備庫必須以-ss為后綴
三、表設計規(guī)范
單實例表個數(shù)必須控制在2000個以內
單表分表個數(shù)必須控制在1024個以內
表必須有主鍵,推薦使用UNSIGNED整數(shù)為主鍵
注意事項:用不用unsigned可以參考一下這個問題:https://www.cnblogs.com/blankqdb/archive/2012/11/03/blank_qdb.html
潛在坑:刪除無主鍵的表,如果是row模式的主從架構,從庫會掛住
禁止使用外鍵,如果要保證完整性,應由應用程式實現(xiàn)
解讀:外鍵使得表之間相互耦合,影響update/delete等SQL性能,有可能造成死鎖,高并發(fā)情況下容易成為數(shù)據(jù)庫瓶頸
建議將大字段,訪問頻度低的字段拆分到單獨的表中存儲,分離冷熱數(shù)據(jù)
四、列設計規(guī)范
根據(jù)業(yè)務區(qū)分使用tinyint/int/bigint,分別會占用1/4/8字節(jié)
根據(jù)業(yè)務區(qū)分使用char/varchar
解讀:
(1)字段長度固定,或者長度近似的業(yè)務場景,適合使用char,能夠減少碎片,查詢性能高
(2)字段長度相差較大,或者更新較少的業(yè)務場景,適合使用varchar,能夠減少空間
根據(jù)業(yè)務區(qū)分使用datetime/timestamp
注意事項: 可以參考這篇文章:https://blog.51cto.com/hanchaohan/1751447
解讀:前者占用5個字節(jié),后者占用4個字節(jié),存儲年使用YEAR,存儲日期使用DATE,存儲時間使用datetime
必須把字段定義為NOT NULL并設默認值 ,可以參考這個文章:
https://blog.csdn.net/u010737354/article/details/53081830
https://www.cnblogs.com/balfish/p/7905100.html
解讀:
(1)NULL的列使用索引,索引統(tǒng)計,值都更加復雜,MySQL更難優(yōu)化
(2)NULL需要更多的存儲空間
(3)NULL只能采用IS NULL或者IS NOT NULL,而在=/!=/in/not in時有大坑
使用INT UNSIGNED存儲IPv4,不要用char(15)
解讀:
(1)如果用CHAR(15)來存儲,則需要15個字節(jié)(VARCHAR則需要16個字節(jié))。將IP用無符號整數(shù)存儲,只需要4個字節(jié),能節(jié)約空間。
(2)對于范圍查找效率更高
SELECT * FROM test_han WHERE ip BETWEEN INET_ATON('192.168.0.0') AND INET_ATON('192.168.0.255');
(3)SELECT * FROM test_han WHERE ip = INET_ATON('192.168.0.0');
SELECT INET_ATON('192.168.0.0');
SELECT INET_NTOA(3232235520);
可以參考一下這篇文章:http://www.voidcn.com/article/p-dnqfznsx-mc.html
使用varchar(20)存儲手機號,不要使用整數(shù)
解讀:
(1)牽扯到國家代號,可能出現(xiàn)+/-/()等字符,例如+86
(2)手機號不會用來做數(shù)學運算
(3)varchar可以模糊查詢,例如like ‘138%’
使用TINYINT來代替ENUM
解讀:ENUM增加新值要進行DDL操作
五、索引規(guī)范
唯一索引使用uniq_[字段名]來命名
非唯一索引使用idx_[字段名]來命名
單張表索引數(shù)量建議控制在5個以內
索引參考:https://blog.51cto.com/hanchaohan/926580
解讀:
(1)互聯(lián)網(wǎng)高并發(fā)業(yè)務,太多索引會影響寫性能
(2)生成執(zhí)行計劃時,如果索引太多,會降低性能,并可能導致MySQL選擇不到最優(yōu)索引
(3)異常復雜的查詢需求,可以選擇ES等更為適合的方式存儲
組合索引字段數(shù)不建議超過5個
解讀:如果5個字段還不能極大縮小row范圍,八成是設計有問題
不建議在頻繁更新的字段上建立索引
非必要不要進行JOIN查詢,如果要進行JOIN查詢,被JOIN的字段必須類型相同,并建立索引
解讀:踩過因為JOIN字段類型不一致,而導致全表掃描的坑么?
理解組合索引最左前綴原則,避免重復建設索引,如果建立了(a,b,c),相當于建立了(a), (a,b), (a,b,c)
六、SQL規(guī)范
禁止使用select *,只獲取必要字段
解讀:
(1)select *會增加cpu/io/內存/帶寬的消耗
(2)指定字段能有效利用索引覆蓋
(3)指定字段查詢,在表結構變更時,能保證對應用程序無影響
insert必須指定字段,禁止使用insert into T values()
解讀:指定字段插入,在表結構變更時,能保證對應用程序無影響
隱式類型轉換會使索引失效,導致全表掃描
禁止在where條件列使用函數(shù)或者表達式
解讀:導致不能命中索引,全表掃描
禁止負向查詢以及%開頭的模糊查詢
解讀:導致不能命中索引,全表掃描
禁止大表JOIN和子查詢
同一個字段上的OR必須改寫問IN,IN的值必須少于50個
應用程序必須捕獲SQL異常
解讀:方便定位線上問題
說明:上面建議用于并發(fā)量大,數(shù)據(jù)量大的典型互聯(lián)網(wǎng)業(yè)務
新聞名稱:MySQL在互聯(lián)網(wǎng)業(yè)務使用建議
網(wǎng)站URL:http://www.ef60e0e.cn/article/psgjhh.html