我們今天給大家分享MySQL 設計規范中幾個常見的誤區，希望以后的數據庫設計可以規避掉。

1、主鍵的設計

誤區：主鍵建議使用自增 ID 值，盡量不要使用 UUID，MD5，HASH，字符串作為數據庫主鍵

自增主鍵的優點：占用空間小，有序，使用起來簡單。

自增主鍵的不足：

• 自增值由于在服務器端產生，需要有一把自增的 ?鎖保護，如果業務有大量的插入請求，就可能引起的性能瓶頸。

• 自增值做數據庫主鍵，只能在當前數據庫實例中保證唯一，不能保證全局唯一，無法在分布式架構中使用。

• 存在數據安全，如果我們的商品 ID 是采用自增主鍵的話，用戶可以通過修改 ID 值來獲取商品，甚至可以知道我們數據庫中一共存了多少個商品。

• MGR（MySQL Group Replication） 可能引起的性能問題；

?MySQL使用 UUID() 函數來獲取 UUID 的值。

MySQL> select UUID(); +--------------------------------------+ | UUID() | +--------------------------------------+ | 15ebaa88-ce00-11eb-b431-123ac110002 | +--------------------------------------+ 1 row in set (0.00 sec)

需要特別注意的是，在存儲時間類型時，UUID 是根據時間位逆序存儲，?也就是低時間低位存放在最前面，高時間位在最后，即 UUID 的前 4 個字節會隨著時間的變化而不斷“隨機”變化，并非單調遞增。而非隨機值在插入時會產生離散 IO，從而產生性能瓶頸。這也是 UUID 對比自增值最大的不足之處。

為了解決這個問題，MySQL 8.0 推出了函數 UUID_TO_BIN，它可以把 UUID 字符串：

• 通過參數將時間高位放在最前，解決了 UUID 插入時亂序問題；

• 去掉了無用的字符串"-"，精簡存儲空間；

• 將字符串其轉換為二進制值存儲，空間最終從之前的 36 個字節縮短為了 16 字節。

下面我們將之前的 UUID 字符串 23ebaa88-ce89-11eb-b123-123ac110002 通過函數 UUID_TO_BIN 進行轉換，得到二進制值如下所示：

MySQL> SELECT UUID_TO_BIN('23ebaa88-ce89-11eb-b123-123ac110002',TRUE) as UUID_BIN; +------------------------------------+ | UUID_BIN | +------------------------------------+ | 0x11EBCE8923EBAA88B4310242AC110002 | +------------------------------------+ 1 row in set (0.01 sec)

MySQL 8.0 也提供了函數 BIN_TO_UUID，可以支持將二進制值轉化為 UUID 字符串。

MySQL 8.0 之前的版可以通過自定義函數的方式解決。業務層的話可以根據相應的編程語言編寫相應的函數。

而且由于 UUID 能保證全局唯一，因此使用 UUID 的好處遠遠大于自增 ID。可能你已經習慣了用自增做主鍵，但是在并發場景下，更推薦 UUID 這樣的全局唯一值做主鍵。

但是在分布式場景下，主鍵還需要加入一些額外的信息，這樣才能保證后續二級索引的查詢效率，建議根據業務自定義生成主鍵。但是在并發量和數據量沒那么大的情況下，還是建議使用自增 UUID 的。

2、子查詢的使用

錯誤的設計規范：避免使用子查詢

其實這個規范對老MySQL 8.0之前的版本來說是對的，因為之前版本的 MySQL 數據庫對子查詢優化存在很多不足，所以很多 OLTP 業務場合下，很多企業都要求在線業務避免使用子查詢。

MySQL 8.0 版本中，子查詢的優化得到大幅提升，所以在新版本的MySQL中可以放心的使用子查詢。

采用子查詢相比 JOIN 更易于閱讀習慣。

3、枚舉字段的使用

誤區：數據庫字段設計避免使用 ENUM 類型

在以前開發項目中，遇到用戶性別，業務狀態，星期等字段的時候，經常會簡單的將字段設計為 tinyint，然后在字段注釋里面說明?。

存在問題：

• 表達不清：數據表可能是其他同事設計的，你不可能每個都記得住，每次都可能需要去看字段注釋，甚至有時候在編碼的時候需要去數據庫確認字段的具體含義

• 臟數據：雖然在應用層可以通過代碼限制插入的數值，但是還是可以通過sql和可視化工具修改值

固定選項值的字段，推薦使用 ENUM 枚舉字符串類型，再加上SQL_MODE 的嚴格模式

在MySQL 8.0.16 以后的版本，可以直接使用check約束機制，可以不使用enum枚舉字段類型

而且我們一般在定義枚舉值的時候使用"Y","N"等單個字符，并不會占用很多空間。針對選項值不固定的情況，隨著業務發展可能會增加，才不推薦使用枚舉字段。

3、索引個數限制

誤區：限制每張表上的索引數量，索引不能超過 5 個

MySQL 單表的索引沒有個數限制，要根據業務查詢有具體需要，創建即可，不要太在意索引個數的限制。

4、金融字段的設計規范

誤區：同財務相關的金額類數據必須使用 decimal 類型?

由于 float 和 double 都是非精準的浮點數類型，而 decimal 是精準的浮點數類型。所以一般在設計用戶余額，商品價格等金融類字段一般都是使用 decimal 類型，可以精確到分。

但是在海量數據互聯網業務的設計規范中，不推薦用 DECIMAL 數據類型，而是推薦將 DECIMAL 轉化為整型數據類型。?金融類型更適合使用用分單位存儲，而不是用元單位存儲。比如5元在數據庫中用整型類型 500 存儲。

?bigint 類型的優點：

• decimal 是采用二進制實現的一種編碼方式，計算效率不如 bigint

• 使用 bigint 的話，字段是定長字段，存儲高效，而 decimal 根據定義的寬度決定，在數據設計中，定長存儲性能更好

• 使用 bigint 存儲分為單位的金額，也可以存儲千兆級別的金額數據，完全夠用。

總結

• UUID 也可以當主鍵，自增 UUID 比自增主鍵性能更好，多占用的空間也可忽略不計

• 金融字段除了 decimal，也可以試試 bigint，存儲分為單位的數據

• 對于固定選項值的字段，MySQL8 以前推薦使用枚舉字段，MySQL8 以后使用check函數約束，不要使用 0，1，2 表示

• 一張表的索引個數并沒有限制不能超過5個，可以根據業務情況

• MySQL8 對子查詢有了優化，可以放心使用。

IT技術分享社區

個人博客網站：https://programmerblog.xyz

文章推薦程序員效率：畫流程圖常用的工具程序員效率：整理常用的在線筆記軟件遠程辦公：常用的遠程協助軟件，你都知道嗎？51單片機程序下載、ISP及串口基礎知識硬件：斷路器、接觸器、繼電器基礎知識

總結

以上是生活随笔為你收集整理的数据库：MySQL常见的设计规范误区的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。