前言

一位朋友正在后臺(tái)留言。我希望我能談?wù)勗谠O(shè)計(jì)數(shù)據(jù)庫表時(shí)我踩到的坑。那么，讓我們談?wù)勎以谠O(shè)計(jì)數(shù)據(jù)庫表時(shí)遇到的問題，現(xiàn)在我對(duì)數(shù)據(jù)庫表設(shè)計(jì)提出了一些建議。我希望能幫助你。

　　utf8的鍋

在場(chǎng)景:之前，當(dāng)您為客戶進(jìn)行微購時(shí)，您需要保存微信的授權(quán)信息。這時(shí)，有一個(gè)昵稱字段。在設(shè)計(jì)數(shù)據(jù)表時(shí)，表的存儲(chǔ)格式下意識(shí)地設(shè)置為utf8，并且偶爾在生產(chǎn)上線一段時(shí)間后出現(xiàn)。保存例外。經(jīng)過分析，異常的原因是：用戶昵稱有一個(gè)電子郵件表情符號(hào)。不會(huì)產(chǎn)生utf8格式數(shù)據(jù)表存儲(chǔ)。

經(jīng)驗(yàn)提示：在設(shè)計(jì)數(shù)??據(jù)表時(shí)，請(qǐng)務(wù)必注意字段中存儲(chǔ)的內(nèi)容。如果允許設(shè)置表達(dá)式，則不能使用utf8，而是使用utf8mb4。

選擇合適的類型

在數(shù)據(jù)庫表的設(shè)計(jì)中，字段的類型確實(shí)不是很好的設(shè)計(jì)，這里有一個(gè)簡單的陳述：

保存電話號(hào)碼的字段，使用varchar（20）就足夠了，它不應(yīng)該設(shè)計(jì)為varchar（100），設(shè)置為varchar（100）只會(huì)消耗更多的存儲(chǔ)和內(nèi)存開銷，不值得損失！

保存布爾類型，使用tinyint就足夠了，無需設(shè)計(jì)int，甚至bigint。

如果數(shù)據(jù)類型設(shè)計(jì)得太大，則會(huì)造成不必要的浪費(fèi)（磁盤，內(nèi)存，CPU）。最重要的是，這是一項(xiàng)吃力不討好的任務(wù)。

　主外鍵字段類型不一致

主要外鍵類型不一致。說到它，你可能不相信它，但在設(shè)計(jì)數(shù)據(jù)庫表時(shí)，它是不顯眼和不一致的，并埋沒了隱式類型轉(zhuǎn)換的坑。如下:

用戶表:

創(chuàng)建表t_base_user（

Oid bigint（20）not null主鍵auto_increment comment'primary key'，....

）

注意，此時(shí)的主鍵oid是bigint（20）。

用戶地址表：

創(chuàng)建表t_base_user_address（

Oid bigint（20）not null主鍵auto_increment comment'主鍵'，

User_id varchar（30）null comment'user id'....

）

您看，此時(shí)t_base_user_address表中的user_id外鍵字段在設(shè)計(jì)時(shí)是varchar（30）。你可能覺得你不能犯這樣的錯(cuò)誤。如果你說，你不怕笑話。我已多次踩過這樣的坑。當(dāng)我發(fā)現(xiàn)慢速SQL時(shí)，我發(fā)現(xiàn)自己陷入了這樣的困境！ ！ ！

　注釋

在數(shù)據(jù)庫表設(shè)計(jì)之前，沒有添加注釋的習(xí)慣，直接后果是：一旦數(shù)據(jù)庫設(shè)計(jì)階段，使用后續(xù)數(shù)據(jù)表，字段名稱都是猜測(cè)。我們編寫代碼以了解注釋非常重要，并且在設(shè)計(jì)數(shù)據(jù)庫表時(shí)注釋也非常重要！一定要記得添加注釋，無論是表，還是字段，索引，都必須添加注釋。

如:

創(chuàng)建表t_base_user（

Oid bigint（20）not null主鍵auto_increment comment'primary key'，....

）

已添加現(xiàn)有注釋

更改表t_base_user修改oid bigint（20）not null主鍵auto_increment comment'primary key';

添加注釋時(shí)，還需要注意的是，在某些需要計(jì)算的字段上，需要添加指向計(jì)算規(guī)則文檔的鏈接。方便后續(xù)搜索！

　加索引

如前一篇文章所述，良好的數(shù)據(jù)表設(shè)計(jì)應(yīng)考慮在開頭添加索引。在這個(gè)階段添加索引的成本不僅是最低的。并且仍然不要對(duì)后續(xù)行動(dòng)，甚至生產(chǎn)事故的隱患進(jìn)行緩慢的查詢！如何添加索引，索引并不重要，可以查看《寫會(huì)MySQL索引》文章查看！嘿，我沒有索引或忘記添加索引就吃掉了很多損失。記憶仍然新鮮！ ！ ！

　小結(jié)

以上是我設(shè)計(jì)桌子時(shí)所處的坑。以下是簡化版本:

允許保存表的表達(dá)式，存儲(chǔ)格式設(shè)計(jì)為utf8mb4，避免使用utf8。

選擇正確的數(shù)據(jù)類型。

主外鍵字段類型必須一致，否則會(huì)導(dǎo)致隱式轉(zhuǎn)換，不去索引，導(dǎo)致生產(chǎn)事故！

在表格和字段中添加合理的注釋。

設(shè)計(jì)數(shù)據(jù)庫表時(shí)，請(qǐng)務(wù)必在外鍵字段和相應(yīng)字段中添加索引。

以上是我遇到踩踏坑經(jīng)驗(yàn)后數(shù)據(jù)庫表設(shè)計(jì)的經(jīng)驗(yàn)。有些坑真的花了很多時(shí)間來填補(bǔ)。在這里記錄，如果它可以幫助你，那將是偉大的！

« Piggy CMS智能餐廳：餐飲O2O行業(yè)解決方案 | 扎克伯格的家人歡迎第二個(gè)孩子。這位億萬富翁仍然想要另一個(gè)妓女 »