資料庫設計規範

資料庫命名規範

資料庫基本設計規範

資料庫索引設計規範

資料庫字段設計規範

資料庫sql開發規範

資料庫操作行為規範

規範一：所有資料庫物件名稱必須使用小寫字母並用下劃線分割。

原因： mysql大小寫敏感，全部命名小寫方便開發。

例子：不同資料庫名dbname 和 dbname是兩個不同資料庫。

規範二：所有資料庫物件名稱禁止使用mysql保留關鍵字。

原因：語句識別不了，如果硬要使用，需要使用轉移符號標註。

例子：select id,from,age from table;mysql他會查詢報錯。

參考：規範三：資料庫物件的命名要能做到見名識義，並且不要操作32個字元。

原因：佔空間並且不好維護。

例子：使用者資料庫mc_userdb(慕課使用者的db)；使用者賬號表user_account()。

規範四：臨時表必須以tmp為字首並以日期為字尾。

規範五：備份表，備份表必須以bak為字首以日期為字尾。

規範六：所有儲存相同資料的列名和列型別必須一致。

原因：可以加快查詢，因為大部分相同的列名，是用來關聯的，查詢的時候，關聯欄位會通過對比統一，如果兩個欄位的屬性不同，mysql會轉換同一型別作比較。

規範一：所有表必須使用innodb引擎。

原因：mysql5.6以後為預設引擎，支援事物，行級鎖，很好的恢復性，高併發效能更好。

規範二：資料庫和表的字符集統一使用utf8。

原因：統一字符集可以避免由於字符集轉換產生的亂碼。

注意：mysql中utf8字符集漢字占用3個位元組，ascii碼占用1個位元組。

規範三：所有表和字段都需要新增注釋。

原因：從一開始就進行資料字典的維護。

規範四：盡量控制單標資料的大小，建議控制在500萬以內。

注意：500萬並不是mysql資料庫的限制，限制取決於儲存設定和檔案系統。j

** 規範五**：謹慎使用mysql分割槽表。

原因：分割槽表在物理上表現為多個檔案，在邏輯上表現為乙個表。

例如：分割槽訂單表，以訂單號作為分割槽標識，如果你查詢某個人的訂單，可能就需要遍歷所有分割槽，這樣物理分表方式管理大資料表更好。（看情況而定）

規範六：盡量做到冷熱資料分離，減少表的寬度。

原因：減少磁碟io，保證熱資料的記憶體快取命中率。磁碟io影響mysql效能是很大的。利用更有效的快取，避免讀入無用的冷資料。

注意：mys限制最多儲存4096列。

規範七：禁止在表中簡歷預留字段。

原因：預留欄位的命名很難做到見名識義，無法確定儲存的資料型別，對預留字段型別的修改，會對錶進行鎖定，加列比修改開銷更大。

規範一：限制每張表的索參數量，建議單張表索引不超過5個

原因：索引並不是越多越好，索引可以提高效率同樣可以減低效率

注意：innodb按照主鍵索引的順序來組織表的，如果沒主鍵，會使用第乙個非空作主鍵，沒有的話，會生成乙個6個位元組的列作隱藏主鍵。不要使用uuid，md5，hash，字串列作為主鍵，索引順序會亂，導致io操作變多。

建議：常見索引列1、奪標join的關聯列，2、select或update

規範二：聯合索引區分度最高的列放在聯合索引的最左側

規範三：聯合索引盡量把字段長度小的列放在聯合索引的最左側

規範四：聯合索引使用最頻繁的列放到聯合索引的左側（基於二和三）

規範五：對於頻繁的查詢有限考慮使用覆蓋索引

注意：覆蓋索引就是把頻繁查詢的列也寫進索引，那麼mysql就不需要在執行二次查詢，直接使用索引查詢到的資訊返回給使用者。

規範六：盡量避免使用外來鍵

原因：外來鍵會影響父表和子表的寫操作從而減低效能。

注意：不建議使用外來鍵約束，建議使用索引；並且實現關聯可以在業務邏輯上實現。

規範一：優先選擇符合儲存需要的最小的資料型別

注意：varchar（n）中的n代表的是字元數，而不是位元組數。使用utf8儲存漢字varchar(255)=765g個位元組。

例子：1、將字串轉化為數字型別儲存；inet_aton(『255.255.255.255』) = 4294967295;inet_ntoa(4294967295) = 『255.255.255.255』。

2、對於非負資料採用無符號整形儲存；有符號和無符號占用的記憶體空間前者是後者的兩倍；

規範二：避免使用text、blob資料型別

建議1：建議把blob或是text分離到單獨的擴充套件表中，text和blob只能使用字首索引。

規範三：避免使用enum資料型別

原因：enum資料型別，儲存形式內部是以整形儲存的。使用order by操作率低，需要轉為整形在進行排序。修改enum值需要使用alter語句，多列的修改，出現的io操作會變多，而且會出現操作失誤的風險。

規範四：盡可能把所有列定義為not null

原因：索引null列需要額外的空間儲存，所以要占用更多的空間；進行比較和計算時要對null值做特別的處理；null儲存記憶體比not null要大。

規範五：使用timestamp或datetime型別儲存時間

原因：字串儲存要十乙個位元組，但datetime只需要八個，無法使用日期函式進行計算和比較。

規範一：建議使用預編譯語句進行資料庫操作

原因：減少網路頻寬，一次解析多次使用，只穿引數，比傳遞sql更快，避免sql注入；避免資料型別的隱式轉換；

例如：select id from table where id = 『113』;

規範二：充分利用表上已經存在的索引

例如：避免使用雙%號的查詢條件；乙個sql只能利用到符合索引中的一列進行範圍查詢（聯合索引範圍查詢欄位放右側）；使用left join或not exists來優化not in操作；

規範三：程式連線不同的資料庫使用不同的賬號，禁止跨庫查詢

原因：為資料庫遷移和分庫分表留出餘地；降低業務耦合度；避免許可權過大導致出的風險；

規範四：禁止使用select *查詢

原因：消耗記憶體；無法使用覆蓋索引；當新增新的列時，出現不必要的錯誤；

規範五：避免使用子查詢，可以把子查詢有華為join操作

原因：子查詢的結果集無法使用索引；子查詢會闡釋臨時表，如果查詢資料量大則嚴重影響效率；消耗過多的cpu的io資源；（如果子查詢是簡單的查詢可以適當使用）

規範六：避免使用join關聯太多的表

原因：每join乙個表會多占用一部分記憶體；會產生臨時表操作，影響查詢效率；mysql最多允許關聯61個表，建議不超過5個；

規範七：減少通資料庫的互動次數

原因：資料庫更適合處理批量操作；合併多個相同的操作到一起，可以提高處理效率；

規範八：使用in代替or

原因：in的值不要超過500個；in操作可以有效的利用索引；

規範九：禁止使用order by rand（）進行隨機排序

原因：會把表中所有符合條件的資料裝載到記憶體中進行排序；會消耗大量cpu和io及記憶體操作；推薦在程式中獲取乙個隨機值，然後從資料庫中獲取隨機資料。

規範十：where從句中禁止對列進行函式轉換和計算

原因：對列進行函式轉換或計算會導致索引失效；

例子：where date（createtime）=『20160901』和where createtime>=『20160901』 and createtimr<'20160902』是一樣的效果；

規範十一：在明顯不會有重複值時使用union all而不是union

原因：union會把所有資料放到臨時表中後會進行去重操作；union all不會對資料進行操作；

規範十二：拆分複雜的大sql為多個小sql；

原因：mysql乙個sql只能使用乙個cpu進行計算；sql拆分後可以通過並執行來提高處理效率；

規範一：超100萬行的批量寫操作，要分批多次進行操作

原因：大批量操作可能會造成嚴重的主從延遲；binlog日誌為row格式時會產生大量日誌；避免產生大事務操作；

規範二：對大表資料庫使用pt-online-schema-change修改表結構

原因：避免達標修改產生的主從延遲；避免在對表字段進行修改時進行鎖表；pt-online-schema-change是在修改表時，會生成乙個新錶，然後再從舊表中複製資料到新錶，每新增一條會帶有乙個時間很短的時間鎖，分批次進行修改。

規範三：禁止為程式使用的賬號賦予super許可權

原因：當達到最大連線數限制時，還允許1個有super許可權的使用者連線；super許可權只能留給dba處理問題的賬號使用。

規範四：對於程式連線資料庫賬號，遵循許可權最小原則

原因：程式使用資料庫賬號只能在乙個db下使用，不准跨庫；程式使用的賬號原則上不准有drop許可權。（系統幾乎不會用上drop等操作，處理資料維護）

資料庫設計規範

資料庫設計規範

資料庫設計規範

資料庫設計規範

相關推薦