01_數據庫設計規範

【數據庫設計規範】

數據庫命名規範

數據庫基本設計規範

數據庫索引設計規範

數據庫字段設計規範

SQL開發規範

數據庫操做規範

 

【1.數據庫命名規範】

1.全部數據庫對象名稱必須使用小寫字母並用下劃線分割

 MySql是區分大小寫的，若是設計時用了大小寫，可能會出現下面凌亂的狀況

不一樣的數據庫名   dbName   dbname

不一樣的表名    Table  table   tabLe

2.全部數據庫對象名稱禁止使用MySql保留關鍵i字

3.數據庫對象的命名要作到見名識義，而且最好不要超過32個字符

4.臨時庫、表必須以tmp爲前綴而且以日期爲後綴

5.備份庫、表必須以bak爲前綴而且以日期爲後綴

6.全部存儲相同數據的列名和列類型必須一致

 

【2.數據庫基本設計規範】

1.MySql5.5使用以前Myisam（默認存儲引擎）的狀況，建議使用InnoDB存儲引擎。

InnoDB是5.6之後默認的存儲引擎，其支持事務、行級鎖、更好的恢復性、高併發下性能更好。

2.數據和表的字符集建議統一使用UTF-8

　　統一字符集能夠避免因爲字符集轉換產生的亂碼。

　　注意：MySql中UTF-8字符集漢字佔3個字節，ASCII碼佔1個字節。

3.全部表和字段都須要添加註釋

　　使用comment從句添加表和列的備註。

　　從一開始就進行數據字典的維護。

4.儘可能控制單表數據量的大小，建議控制在500萬之內

　　500萬並非MySql數據的限制（修改表結構、備份、恢復都會有很大的問題）

　　MySql最多能夠存儲多少萬數據呢？——這種限制取決於存儲設備和文件系統。

　　若是感受單表數據量過大，能夠採用歷史歸檔、分庫分表等手段來控制數據量大小。

5.謹慎使用MySql分區表

　　分區表在物理上表現爲多個文件，在邏輯上表現爲一個表

　　謹慎使用分區鍵，跨分區查詢效率可能更低。

　　建議採用物理分表的方式管理大數據。

6.儘可能作到冷熱數據分離，減少表的寬度。

　　減小磁盤IO，保證熱數據的內存緩存命中率

　　更有效地利用緩存，避免讀入無用的冷數據

　　將常常一塊兒使用的列放到一個表中。

7.禁止在表中創建預留字段

　　預留字段的命名很難作到見名識意

　　預留字段沒法確認存儲的數據類型，因此沒法選擇合適的類型

　　對預留字段的修改，會對錶進行鎖定

8.禁止在數據庫中存儲圖片、文件等二進制數據

9.禁止在線上作數據庫壓力測試

10.禁止從開發環境、測試環境直連生產環境數據庫

 

【3.索引設計規範】

1.限制每張表上的索引數量，建議單張表的索引不超過5個

　　索引並非越多越好，索引能夠提升查詢效率，也能夠下降插入、更新、查詢效率

　　禁止給表中的每一列都創建單獨的索引。

2.Innodb是按照主鍵索引順序來組織表的，因此每一個Innodb表必須有一個主鍵。

　　不使用更新頻繁的列做爲主鍵，不使用多列主鍵。

　　不使用UUID、MD五、HASH、字符串列做爲主鍵。

　　主鍵建議使用自增ID值。

3.常見索引列建議

　　SELECT、UPDATE、DELETE語句的WHERE從句中的列

　　包含在ORDER BY、GROUP BY、DISTINCT中的字段

　　多表JOIN的關聯列

 4.如何選擇索引列的順序

　　區分度最高的列放在聯合索引的最左側

　　儘可能把字段長度小的列放在聯合索引的最左側

　　使用最頻繁的列放到聯合索引的左側

5.避免創建冗餘索引和重複索引

6.對於頻繁的查詢優先考慮使用覆蓋索引（即包含了全部須要查詢字段的索引）

　　避免Innodb表進行索引的二次查找

　　能夠避免隨機IO變爲順序IO加快查詢效率

7.儘可能避免使用外鍵

　　不建議使用外鍵約束，但必定要在表與表之間的關聯鍵上創建索引。

　　外鍵可用於保證數據的參照完整性，但建議在業務端實現。

　　外鍵會影響父表和子表的寫操做從而減低性能。

 

 【4.數據庫字段設計規範】

 1.優先選擇符合存儲須要的最小的數據類型。

　　將字符串轉化爲數字類型的存儲。  

　　　　 INET_ATON( ' 255.255.255.255 ' ) = 4294967295

　　 　　INET_NTOA( 4294967295 ) = '  255.255.255.255  '

 　　對於非負型的數據來講，要優先使用無符號整型來存儲。

　　　　VARCHAR( N ) 中的N表明的是字符數，而不是字節數

　　　　使用UTF8存儲漢字VARCHAR( 255 ) = 765個字節

2.避免使用TEXT、BLOB數據類型

　　若是必定要使用，建議把TEXT、BLOB列分離到單獨的擴展表中

　　注意：TEXT或BLOB類型只能使用前綴索引

3.避免使用ENUM數據類型

　　修改ENUM值須要使用ALTER語句

　　ENUM類型的ORDER BY 操做效率低，須要額外操做

　　禁止使用數值做爲ENUM的枚舉值

 4.儘量把全部列定義爲NOT NULL

　　索引NULL列須要額外的空間來保存，因此要佔用更多的空間。

　　進行比較和計算時要對NULL值作特別的處理。

5.存儲日期類型的數據不要使用字符串類型，要使用TIMESTAMP或DATETIME類型。

　　使用字符串類型存儲日期的問題：沒法使用日期函數進行計算和比較，且字符串存儲日期會佔用更多的空間。

　　TIMESTAMP  範圍：1970-01-01 00:00:01  ~  2038-01-19 03:14:07

　　TIMESTAMP 佔用4字節和INT相同，但比INT可讀性高。

 　　超出TIMESTAMP取值範圍的使用DATETIME類型

6.同財務相關的金額類數據，必須使用decimal類型

　　decimal類型爲精度浮點數，在計算時不會丟失精度。

　　佔用空間由定義的寬度決定

　　可用於存儲比bigint更大的整數數據。

 

 【5.數據庫SQL開發規範】

 1.建議使用預編譯語句進行數據庫操做。

　　只傳參數，比傳遞SQL語句更高效。

　　相同語句能夠一次解析，屢次使用，提升處理效率。

 2.避免數據類型的隱式轉換

　　隱式轉換會致使索引失效

　　select * from user where id = ' 111 '  #實際id是Long類型

3,.充分利用表上已存在的索引。

　　避免使用 雙% 的查詢條件。 如：like ' %123% '

　　一個SQL只能利用到複合索引中的一列進行範圍查詢

　　使用left join 或 not exists 來優化 not in 操做

4.數據庫設計時，就應該對之後擴展進行考慮。

5.程序鏈接不一樣的數據庫使用不一樣的帳號，禁止跨庫查詢。　　

　　爲數據庫遷移和分庫分表留出餘地。

　　下降業務耦合度。

　　避免權限過大產生的安全風險。

6.禁止使用SELECT *    ，應該使用 SELECT  <字段列表>  進行查詢。

7.禁止使用不含字段列表的 INSERT 語句

8.儘量避免使用子查詢，能夠把子查詢優化爲join操做。

 　　子查詢的結果集沒法使用索引

　　子查詢會產生臨時表操做，若是子查詢數據量大會嚴重影響性能。

　　消耗過多的CPU及IO資源。

9.也要避免使用JOIN關聯太多的表。（關聯的表少能夠接受）

　　每JOIN一個表會多佔用一部份內存（join_buffer_size）

　　會產生臨時表操做，影響查詢效率

　　MySql最多容許關聯61個表，建議不超過5個

10.減小數據庫的交互次數

　　數據庫更適合合理批量操做

　　合併多個相同的操做到一塊兒，能夠提升處理效率

11.使用 in 代替 or

　　in 中的數值不超過500個

　　in 操做能夠有效地利用索引

12.禁止使用order by rand()進行隨機排序

　　這種方式會把符合條件的數據裝載到內存中進行排序。

　　會消耗大量的CPU、IO、內存資源。

　　推薦在程序中獲取一個隨機值，而後從數據庫中獲取數據。

 13.WHERE從句中禁止對列進行函數轉換和計算

　　對列進行函數轉換或計算會致使沒法使用索引

　　

14.在明顯不會有重複值時使用UNION ALL ，而不是UNION

　　UNION會把全部的數據放到臨時表中後再進行去重操做。

　　UNION ALL 不會再對結果集進行去重操做。

15.拆分複雜的大SQL爲多個小SQL

　　MySql一個SQL只能使用一個CPU進行計算。

　　SQL拆分後能夠經過並行執行來提升處理效率。

 

【數據庫操做行爲規範】

1.超過100萬行的批量寫操做，要分批屢次進行操做。

　　大批量的寫操做可能會形成嚴重的主從延遲。

　　binlog日誌爲row格式時會產生大量的日誌。

　　避免產生大事務操做。

2.對大表數據結構的修改必定要謹慎，會形成嚴重的鎖表操做，尤爲是生產環境，是不能忍受的。

　　對於大表使用pt-online-shcema-change修改表結構。

3.禁止爲程序使用的帳號賦予 super 權限。

4.對於程序鏈接數據庫帳號，遵循權限最小原則。

　　程序使用數據庫帳號只能在一個DB下使用，不許跨庫。

　　程序使用的帳號原則上是不能有drop權限的。