一、命名規(guī)范

?

• 庫名、表名、字段名必須使用小寫字母并采用下劃線分割；

• 庫名、表名、字段名禁????止超過32個字符，須見名知意；

• 庫名、表名、字段名支持最多64個字符，統(tǒng)一規(guī)范、易于辨識以及減少傳輸量不要超過32；

• 庫名、表名、字段名禁止使用MySQL保留關(guān)鍵字；

• 臨時庫、臨時表名必須以tmp為前綴并以日期為后綴；

• 備份庫、備份表名必須以bak為前綴并以日期為后綴；

?

二、基本規(guī)范

?

• 使用INNODB存儲引擎

  5.5版本以后的默認(rèn)引擘，支持事務(wù)，行級鎖，更好的恢復(fù)性，高并發(fā)下性能更好，對多核，大內(nèi)存，ssd等硬件支持更好

• 表字符集使用utf8mb4(?5.5.3版本以上支持)

• 所有表都需要添加注釋，單表數(shù)據(jù)量建議控制在1000萬以內(nèi)；

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

• 禁止在線上做數(shù)據(jù)庫壓力測試；

• 禁止從測試、開發(fā)環(huán)境直連數(shù)據(jù)庫；

?

三、庫表設(shè)計規(guī)范

?

• 禁止使用分區(qū)表

  MySQL的分區(qū)表實(shí)際性能不是很好，且管理維護(hù)成本較高

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

• 用HASH進(jìn)行散表，表名后綴使用十進(jìn)制數(shù)，下標(biāo)從0開始

  首次分表盡量多的分，避免二次分表，二次分表的難度和成本較高

• 按日期時間分表需符合YYYY[MM][DD][HH]格式

• 采用合適的分庫分表策略，如千庫十個表、十庫百表等

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

?

四、索引設(shè)計規(guī)范

?

????索引是一把雙刃劍，它可以提高查詢效率但也會降低插入和更新的速度并占用磁盤空間

• 單張表中索引數(shù)量不超過5個

• 單個索引中的字段數(shù)不超過5個

  對字符串使用前綴索引，前綴索引長度不超過10個字符；如果有一個

  CHAR(200)列，如果在前10個字符內(nèi)，多數(shù)值是惟一的，那么就不要對整個列進(jìn)行索引。對前10個字符進(jìn)行索引能夠節(jié)省大量索引空間，也可能會使查詢更快

• 表必須有主鍵

• 不使用更新頻繁地列作為主鍵

• 盡量不選擇字符串列作為主鍵

• 不使用UUID、MD5、HASH作為主鍵

• 默認(rèn)使用非空的唯一鍵

• 主鍵建議選擇自增或發(fā)號器重要的SQL必須被索引：

  SELECT、UPDATE、DELETE語句的WHERE條件列ORDER BY、GROUP BY、DISTINCT的字段多表JOIN的字段

• 區(qū)分度最大的字段放在索引前面

• 核心SQL優(yōu)先考慮覆蓋索引

  select的數(shù)據(jù)列只用從索引中就能夠取得，不必讀取數(shù)據(jù)行，換句話說查詢列要被所建的索引覆蓋

• 避免冗余或重復(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)建，每個額外的索引都要占用額外的磁盤空間，并降低寫操作的性能

• 不在低基數(shù)列上建立索引，例如‘性別’

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

• 盡量不要使用外鍵

  外鍵用來保護(hù)參照完整性，可在業(yè)務(wù)端實(shí)現(xiàn)， 對父表和子表的操作會相互影響，降低可用性INNODB本身對Online DDL的限制

• 不使用%前導(dǎo)的查詢，如like“%xxx”，無法使用索引

• 不使用反向查詢，如not in / not like

  無法使用索引，導(dǎo)致全表掃描，全表掃描導(dǎo)致bufferpool利用降低

?

五、字段設(shè)計規(guī)范

?

• 盡可能不要使用TEXT、BLOB類型

  刪除這種值會在數(shù)據(jù)表中留下很大的"空洞"，可以考慮把BLOB或TEXT列分離到單獨(dú)的表中

• 用DECIMAL代替FLOAT和DOUBLE存儲精確浮點(diǎn)數(shù)

  浮點(diǎn)數(shù)相對于定點(diǎn)數(shù)的優(yōu)點(diǎn)是在長度一定的情況下，浮點(diǎn)數(shù)能夠表示更大的數(shù)據(jù)范圍；浮點(diǎn)數(shù)的缺點(diǎn)是會引起精度問題

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

• 使用TINYINT來代替ENUM類型

• 字段長度盡量按實(shí)際需要進(jìn)行分配，不要隨意分配一個很大的容量

  the best strategy is to allocate only asmuch space as you really need

  VARCHAR(N)，N表示的是字符數(shù)不是字節(jié)數(shù)，比如VARCHAR(255)，可以最大可存儲255個漢字，需要根據(jù)實(shí)際的寬度來選擇NVARCHAR(N)，N盡可能小，因?yàn)镸ySQL一個表中所有的VARCHAR字段最大長度是65535個字節(jié)，進(jìn)行排序和創(chuàng)建臨時表一類的內(nèi)存操作時，會使用N的長度申請內(nèi)存

• 如果可能的話所有字段均定義為not null

• 使用UNSIGNED存儲非負(fù)整數(shù)

  同樣的字節(jié)數(shù)，存儲的數(shù)值范圍更大。如tinyint有符號為-128-127，無符號為0-255

• INT類型固定占用4個字節(jié)存儲

• 使用TIMESTAMP存儲時間

  因?yàn)門IMESTAMP使用4字節(jié)，DATETIME使用8個字節(jié),同時TIMESTAMP具有自動賦值以及自動更新的特性

• 使用INT UNSIGNED存儲IPV4

• 使用VARBINARY存儲大小寫敏感的變長字符串

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

?

六、SQL設(shè)計規(guī)范

?

• 使用預(yù)編譯語句prepared statement

  只傳參數(shù)，比傳遞SQL語句更高效

  一次解析，多次使用

  降低SQL注入概率

• 盡量避免相同語句由于書寫格式的不同，而導(dǎo)致多次語法分析

• 避免隱式轉(zhuǎn)換

  會導(dǎo)致索引失效，如selectuserid from table where userid=’ 1234’

• 充分利用前綴索引

  必須是最左前綴

  不可能同時用到兩個范圍條件

• 避免使用存儲過程、觸發(fā)器、EVENTS等

  讓數(shù)據(jù)庫做最擅長的事

  降低業(yè)務(wù)耦合度，為sacleout、shading留點(diǎn)余地

  避開BUG

• 避免使用大表的join

  MySQL最擅長的是單表的主鍵/二級索引查詢

  Join消耗較多的內(nèi)存，產(chǎn)生臨時表

• 避免在數(shù)據(jù)庫中進(jìn)行數(shù)學(xué)運(yùn)算

  容易將業(yè)務(wù)邏輯和DB耦合在一起

  MySQL不擅長數(shù)學(xué)運(yùn)算和邏輯判斷

  無法使用索引

• 減少與數(shù)據(jù)庫的交互次數(shù)

  Insert…on duplicate key update

  Replace into、insert ignore、insert into values(),(),()…

  Update…where id in (1,2,3,4)

  Alter table tbl_name add column col1, addcolumn col2

• 拒絕大SQL，拆分成小SQL

  充分利用querycache

  充分利用多核CUP

• 使用in代替or，in的值不超過1000個

• 禁止使用order by ， rand()

  因?yàn)閛rder by，rand()會將數(shù)據(jù)從磁盤中讀取，進(jìn)行排序，會消耗大量的IO和CPU，可以在程序中獲取一個rand值，然后通過在從數(shù)據(jù)庫中獲取對應(yīng)的值

• 使用union all而不是union

• 程序應(yīng)有捕獲SQL異常的處理機(jī)制

• 禁止單條SQL語句同時更新多個表

• 不使用select *

  消耗cpu和IO、消耗網(wǎng)絡(luò)帶寬

  無法使用覆蓋索引

  減少表結(jié)構(gòu)變更帶來的影響

  ?

七、行為規(guī)范

?

• 任何數(shù)據(jù)庫的線上操作，必須走工單

• 禁止在主庫上執(zhí)行統(tǒng)計類的功能查詢；

• 禁止有super權(quán)限的應(yīng)用程序賬號存在；

• 有大規(guī)模市場推廣、運(yùn)營活動必須提前通知DBA進(jìn)行流量評估；

• 對單表的多次alter操作必須合并為一次操作；

• 不在MySQL數(shù)據(jù)庫中存放業(yè)務(wù)邏輯；

• 重大項目的數(shù)據(jù)庫方案選型和設(shè)計必須提前通知DBA參與；

• 數(shù)據(jù)必須有備份機(jī)制；

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

總結(jié)

以上是生活随笔為你收集整理的必要商城MySQL开发规范的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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