最近都沒什麽時間來寫比克，工做太忙......

不過這也不是什麽借口。

最近在學習相關知識，寫下來記錄一下吧。

註意：

    這裏的規範並不是絕對的，如果你的團隊已經制定了規範。
    請按照團隊規範來實行。
    如果沒有，請盡量遵循基本規範。並推動制定規範。

數據庫設計規範:

　　1：數據庫名/表名 小寫

　　　　數據庫等於是在 Liunx 上的一個個文件，Linux 是區分大小寫的，所以表/庫也是如此，為了避免在大小寫上引起的錯誤，盡量使用小寫來作為統一規定。

　　2：不使用mysql關鍵字

　　　　關於這個問題，老生常談了吧，不使用 mysql 的關鍵字，也是為了避免錯誤。　　

　　3: 臨時表命名規範

　　　　在實際工作，不免要創建一些臨時表進行工作，而且會有時忘記清理(很大可能).

　　　　最後也忘記了那個是臨時表，所以需要對臨時表的命名做出規範，以便於我們知道那個是臨時表。

　　　　命名規範為：以tmp為前綴-日期為後綴

　　　　例如：tmp_temporary_20180611

　　3: 備份表命名規範

　　　　同上

　　　　命名規範為：bak為前綴_日期為後綴

　　　　例如：例如：bak_temporary_20180611

　　4：儲存相同數據的列名和類類型必須一致

　　　　這裏有兩張表，一個用戶ID，一個文章，文章一個外鍵是user_id

　　　　他們儲存的是同種數據，所以在構建時，他們的數據類型等等必須都一致。

　　　　如果不一致，Mysql 其實是會在內部進行一個隱式的字符轉換，會耗費性能。

　　5：統一使用innodb

　　　　在 mysql5.6 之後，默認引擎已經變為了 Innodb 。

　　　　和 innodb 相比，Myisam 的優勢已經很小了，而且在混用的時候，Myisam 的工作並不是那麽理想。

　　　　所以我們在沒有特殊場景時候，應該默認使用 Innodb。

　　　　它的優勢在很多地方都有 支持行鎖/實務/高並發下效果更好

　　6：統一使用uft8

　　　　字符集一直是一個比較容易被忽視的地方，實際在任何時候，字符集都是一個比較重要的地方。

　　　　混亂的字符集會導致數據的丟失和無法恢復。

　　　　於是需要統一字符集，統一使用uft8。

　　7：表和字符添加註釋

　　　　註釋的意義，不用多言，同時數據表也是需要註釋的。

　　　　從最開始 對於數據字典的維護 是非常有必要的，可以使後面的同學快速明白字段的意義。

　　　　也不會出現公司運轉幾年之後，拿出一張表，沒有一個人能完整說出字段的意義這種窘境。

　　8： 盡量控制單表數據量大小

　　　　之前有人說，mysql的單表最大數是 500萬。

　　　　關於這個並不是一個準確數字，他和操作系統，位數，等等都有關系。

　　　　不過太大，並不是個好事情，對於太大的表

　　　　　　-- 進行歷史數據歸檔

　　　　　　-- 分庫分表

　　9：盡量冷熱分離，減少列數

　　　　盡量把冷熱的數據區分開來,便於使用查詢，提高讀入效率。

　　　　減少表的列數，並不是越多越好， 表列多，在讀入時就會消耗更多的內存。

　　　　建議經常使用的列放入一個列。

　　10: 禁止在表中預留字段

　　　　在開發中，經常會有預留字段的事情發生，因為可能知道之後需要補充一些字段。

　　　　這樣感覺也沒什麽錯，但是卻造成了極大浪費。

　　　　一是由於預留字段無法見名知意，也會使用大字段VARCHAR()來進行存儲。

　　　　在之後修改字段的話也會進行數據庫的鎖表，導致一段時間的服務異常。

　　　　怎麽想都是不合算的，於是在開發時一定要避免這種事情的產生。

　　11：禁止存文件/圖片 等二進制數據

　　　　太大，太長，你懂得

　　 12：禁止在線上做壓力測試/禁止從開發環境_測試 直接連接數據庫

　　　　避免臟數據的產生，建議使用專門搭建的測試環境。　　　　

索引規範

索引並不是越多越好。
大量的索引會使Mysql優化器在選擇時耗費大量的時間。

　　1: 限制每張表的索引數量

　　　　最好不好超過五個,索引不是越多越好，會提高/也會降低索引

　　　　禁止給每一列建立索引，並不會獲得很好的效果

　　2：在哪些列上建立索引？

　　　　在 select/update/delete SQL中的 where 條件中建立索引

　　　　在 order by / group by 字段上建立索引

　　3：如何選擇索引列順序（待研究）

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

　　　　字段長度小的放在聯合索引的最左側

　　　　最頻繁查詢的字段放在聯合索引的最左側

　　4：盡量少使用外鍵

　　　　不建議使用外鍵約束,在使用外鍵約束時，會影響 父/子 的寫性能。

　　　　推薦使用索引

字段設計規範

選擇合適的字段類型會很大程度上提高整體性能

　　-- 優先選擇符合存儲需要的最小數據類型

　　　　-- 字符轉化為數字類型存儲

　　　　-- 對無符號數據采用無符號存儲【省一倍空間】

　　-- 避免 TEXT 這種數據類型

　　　　-- 建議分離到單獨的表中

　　-- 建議把所有列定義為 NOT NULL

　　　　-- 運算時會進行特別處理

　　-- 不建議儲存時間類型為字符串，浪費

　　　　-- 建議使用 DATAETIME/TIMESTAMP 儲存

　　-- 財務相關的，必須使用decial精確浮點類型

　　　　-- 計算不丟失精度

　　　　-- 可以保存比bigint更大的整數數據

-- sql 規範

　　-- 預編譯優點

　　　　只傳參數，跟高效

　　　　防範註入，一次解析，多次使用

　　-- 避免隱式轉換

　　　　-- 可能導致索引失效

　　　　-- select * from user where id = ‘1‘;

　　-- 避免使用 %%/%*使用查詢條件

　　-- 禁止跨庫查詢，連接不同數據庫，使用不同賬號

　　　　-- 為數據庫遷移和分庫分表留出余地

　　　　-- 避免權限過大導風險

　　-- 禁止 select *

　　　　-- 無用數據

　　　　-- 無法使用覆蓋索引

　　-- 禁止使用不含字段列表的insert

　　　　-- ? inster into t values(‘a‘bc)

　　　　-- 避免表結構影響

　　-- 禁止使用子查詢

　　　　-- 修改為 join

　　　　-- 子查詢結果集不能使用索引

　　　　-- 臨時表消耗IO/CPU

　　-- 避免 join 關聯過多表

　　　　-- 多關聯一個表，多耗一份內存

　　　　-- 最多61 建議不超過5個

2018/06/11 數據庫設計規範