MySQL 資料庫規範 設計篇

2021-08-29 21:03:01 字數 3645 閱讀 1661

1.設計階段

2.開發階段

3.調優階段(未開發,pt_query_digest、show_slow_log、查詢優化等)

4.福利彩蛋

1.1 資料庫表的設計正規化(三正規化&反正規化)

為什麼需要正規化

優點:程式設計相對簡單,資料量更小,更適合放入記憶體,更新更快,只需要更新少量的資料,

更少的冗餘意味著更少的需要group distinct 之類的操作。

第一正規化

資料表每一列都是不可分割的基本資料項。舉例乙個人有多個手機號
第二正規化

資料表裡的所有資料都要和該資料表裡的主鍵有完全相依賴的關係,不能只依賴部分。

舉例:使用者名稱&使用者技能 是主鍵,使用者居住地 ,那麼使用者名稱為主鍵就可以了。

第三正規化

正規化的缺陷

查詢變得相當複雜,查詢時需要更多的連線join ,一些復合索引的列由於正規化化的需要被分割到不同的表中,導致索引策略不佳。
反正規化

優點:減少了連線,可以更好的利用索引進行篩選和排序,對查詢操作可以提高效能。

缺點:要在資料一致性與查詢之間找到平衡點,符合業務場景的設計才是好的設計

資料庫設計準則

設計的資料庫應該按照使用者可能的訪問路徑,訪問習慣進行設計,而不是嚴格按照資料正規化來設計
1.2 儲存引擎的選擇

儲存引擎分類

innodb:

1.災難恢復性好

2.支援4中級別的事務,預設事務的隔離級別是repeatable read,事務支援是通過mvcc多版本併發控制來提供的。

3.使用行級鎖,併發效能高。

4.使用此儲存引擎的表,資料的物理組織形式是簇表,資料按主鍵來組織,即主鍵索引和資料是在一起的,b+樹就是這樣的

5.實現緩衝管理,能快取索引也能快取資料。

6.支援外來鍵

7.支援熱備份

myisam:

1.配合鎖,實現作業系統下的複製備份,遷移

2.使用表記鎖併發性差

3.支援全文索引

4.主機宕機後,表容易損壞,災難恢復性不佳

5.無事務支援

6.只快取索引,資料快取利用作業系統緩衝區實現的,引發過多系統呼叫,效能不佳。

7.資料緊湊儲存,可以獲得更快的索引和更快的全表掃瞄效能。

儲存引擎的選擇:

設計階段我們選用innodb儲存引擎作為資料的儲存模式,使用事務、且併發性高,支援外來鍵,支援外來鍵索引。
1.3 字符集選擇

字元編碼採用utf-8

字元校驗採用utf-8-cgi

1.4 命名約定

規範的必要性p187

1.年前bug就是因為沒有建立索引導致的一系列bug,所以建立規範,刻不容緩。

2.命名沒有強制約定,但在乙個應用中建議風格統一。

命名約定

1.命名有意義,一眼知道這張表是幹什麼用的

2.資料庫,表都用小寫

資料庫形如:backend

資料表形如:client_device_info(客戶端裝置資訊),不要縮寫,字母全小寫

3.索引命名以idx_為字首

4.命名不要過長(應盡量少於25字元)

5.不要使用保留字

6.同一欄位在不同的表中也應是相同的型別和長度

7.同一資料庫下有不同的模組,可以考慮對錶名用不同的字首標識

8.備份表時加上時間標識

1.5 索引設計

直接參考

mysql 資料庫索引使用場景&注意事項

1.6 資料表設計與規劃

表設計

1.如果沒有特殊情況,建議選擇inoodb索引

2.每個表都應該有主鍵,可選擇自增字段,或整型字段。例外情況,一些應用會頻繁的基於某些字段進行檢索,設計人員可能認為這些字段/

字組合更適合做主鍵,因為更自然、更高效。

3.(不做強制要求)盡量將字段設定為not null。因為null值的儲存需要額外的空間,且會導致比較運算更為複雜,會使得優化器更難以

優化sql。null 值雖然會導致比較運算更加複雜,但這比因此定義了not null帶來應用邏輯異要好。

4.使用更短小的列,比如整型列。整型列的執行速度往往更快。

5.儲存精確浮點數必須使用decimal代替float和double。

6.建議使用unsigned型別儲存非負值

7.建議使用 int unsigned儲存ipv4

8.整型定義中不新增顯示長度的值,使用int,而不是int(4)

9.盡可能不要使用text,blob型別

10.varchar(n) n表示字元數而不是位元組數,比如varchar(255)最大可儲存255個漢字,需根據實際字元長度選擇n的值。

11.字符集建議選擇utf-8

12.儲存年時使用year型別

13.儲存日期時使用date型別

14.儲存時間時,建議使用timestamp型別,因為timestamp使用的是4位元組,datetime使用的是8位元組。

15.不要在資料庫中使用varbinary或blob儲存及檔案,mysql 並不適合大量儲存這型別檔案

16.join 操作的字段,在不同表中的型別及命名要一致

17.如果更改表結構會影響效能,需要我司後台(有dba盡可能找dba)進行聯合評審。

資料表規劃

檢視資料表大小的指令碼

其中data_length是記錄大總大小,index_length 為索引的大小,table_schema 是資料庫名

table_name 是資料表名。

1.7 慎用外來鍵

外來鍵的使用

1.外來鍵的優點:

外來鍵約束使得程式設計師更不容易將不一致性引入資料庫,而且設計合適外來鍵有助於以文件方式記錄表間關係。

2.外來鍵的缺點

但這些優點是以伺服器為執行必要的檢查而花費額外的開銷為代價的。伺服器進行額外的檢查會影響效能。

其次外來鍵對併發效能的影響很大,因每次修改資料都需要去另外乙個表檢查資料,需要獲取額外的鎖(以確保事務完成之前,父表的記錄不

會被刪除)高併發環境下出現效能問題,更好的辦法是在應用層實現外來鍵約束。

4.福利彩蛋
部落格搬家:大坤的個人部落格

MySQL資料庫設計規範

禁止使用mysql保留關鍵字 資料庫物件的命名要見名識義,並且最好不要超過32個字元 臨時庫表必須以tmp為字首並以日期為字尾 備份庫表必須以bak為字首並以日期為字尾 所有儲存相同資料的列名和列型別必須一致 資料庫和表的字符集統一使用utf 8。所有表和字段都要新增注釋 create table ...

MySQL資料庫設計規範

1.庫名,表名,欄位名必須使用小寫字母,多個單詞中間用下劃線隔開 2.庫名,表名,欄位名支援最多32個字元,易於辨識和減少傳輸量不要超過32 3.庫名,表名,欄位名禁止使用mysql保留關鍵字 4.臨時庫,臨時表名必須以tmp為字首並以日期為字尾 5.備份庫,備份表名必須以bak為字首並以日期為字尾...

MySQL資料庫設計規範

規範背景與目的 mysql資料庫與 oracle sql server 等資料庫相比,有其核心上的優勢與劣勢。我們在使用mysql資料庫的時候需要遵循一定規範,揚長避短。本規範旨在幫助或指導rd qa op等技術人員做出適合線上業務的資料庫設計。在資料庫變更和處理流程 資料庫表設計 sql編寫等方面...