2018/06/11 數據庫設計規範
最近都沒什麽時間來寫比克,工做太忙......
不過這也不是什麽借口。
最近在學習相關知識,寫下來記錄一下吧。
註意:
這裏的規範並不是絕對的,如果你的團隊已經制定了規範。
請按照團隊規範來實行。
如果沒有,請盡量遵循基本規範。並推動制定規範。
數據庫設計規範:
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 數據庫設計規範