MySQL表設(shè)計(jì)時(shí)踩過的坑！
前言
有朋友在后臺留言。希望我能說說我在數(shù)據(jù)庫表設(shè)計(jì)時(shí)踩過的坑。那么，我們今天就來聊聊我在數(shù)據(jù)庫表設(shè)計(jì)時(shí)踩過的坑，以及現(xiàn)在對數(shù)據(jù)庫表設(shè)計(jì)的一點(diǎn)建議。希望能夠幫助到你。
utf8的鍋
場景 : 之前在給客戶做微商城時(shí)，需要保存微信的授權(quán)信息，此時(shí)就有一個(gè)nickname字段，在設(shè)計(jì)數(shù)據(jù)表時(shí)，潛意識的將表的存儲(chǔ)格式設(shè)置為utf8，生產(chǎn)上線一段時(shí)間后偶爾出現(xiàn)保存異常。經(jīng)分析，出現(xiàn)異常的原因是：用戶nickname中有email表情符號。utf8格式的數(shù)據(jù)表存儲(chǔ)不下導(dǎo)致。
經(jīng)驗(yàn)提示： 在設(shè)計(jì)數(shù)據(jù)表時(shí)，一定要注意該字段存儲(chǔ)的內(nèi)容，如果允許設(shè)置表情，則一定不能使用utf8，而是使用utf8mb4。
選擇合適的類型
在數(shù)據(jù)庫表設(shè)計(jì)時(shí)，字段的類型還真不好設(shè)計(jì)，這里簡單說說：
- 保存手機(jī)號的字段，用varchar(20)就已經(jīng)足夠了，就不應(yīng)該設(shè)計(jì)為varchar(100)，設(shè)置為varchar(100)只會(huì)消耗更多的存儲(chǔ)以及內(nèi)存開銷，得不償失啊！
- 保存Boolean類型，使用tinyint就夠了，而不需要設(shè)計(jì)為int，甚至bigint。
數(shù)據(jù)類型設(shè)計(jì)的過大,就會(huì)造成沒必要的浪費(fèi)（磁盤，內(nèi)存,CPU），最主要的是，這是一件費(fèi)力不討好的事情。
主外鍵字段類型不一致
主外鍵類型不一致，說起來，你可能會(huì)不相信，但在數(shù)據(jù)庫表設(shè)計(jì)時(shí)，稍不留神，就不一致，埋下隱式類型轉(zhuǎn)換的坑。如下:
用戶表:
- create table t_base_user(
- oid bigint(20) not null primary key auto_increment comment "主鍵", ....
- )
注意此時(shí)的主鍵oid為bigint(20)。
用戶地址表：
- create table t_base_user_address(
- oid bigint(20) not null primary key auto_increment comment "主鍵",
- user_id varchar(30) null comment "用戶id" ....
- )
你看，此時(shí)在t_base_user_address表中的user_id外鍵字段,設(shè)計(jì)時(shí)的卻是varchar(30)。你可能覺得你不可能發(fā)生這樣的錯(cuò)誤，說出來也不怕你笑話，我就踩過好幾次這樣的坑，到***發(fā)現(xiàn)慢SQL了，才發(fā)現(xiàn)自己中了這樣的坑！?。?/p>
注釋
之前在數(shù)據(jù)庫表設(shè)計(jì)時(shí)，就沒有加注釋的習(xí)慣，造成的直接后果是：數(shù)據(jù)庫設(shè)計(jì)階段一過，后續(xù)數(shù)據(jù)表的使用中，字段名就全靠猜了。我們寫代碼是知道注釋是非常重要的，同樣在設(shè)計(jì)數(shù)據(jù)庫表時(shí)，注釋也非常重要！一定要記住加注釋，無論是表，還是字段，索引，都必須加上注釋。
如:
- create table t_base_user(
- oid bigint(20) not null primary key auto_increment comment "主鍵", ....
- )
已有表加注釋
- alter table t_base_user modify oid bigint(20) not null primary key auto_increment comment "主鍵"；
加注釋時(shí)，還要注意的是：在一些需要計(jì)算的字段上，需要加上計(jì)算規(guī)則文檔的鏈接。方便后續(xù)查找！
加索引
在之前的文章中也有說過，一個(gè)好的數(shù)據(jù)表設(shè)計(jì)，在一開始就應(yīng)該考慮添加索引，這個(gè)階段添加索引成本不僅***。而且還不給后續(xù)留下慢查詢，甚至生產(chǎn)事故的隱患！索引怎么加，索引重不重要，可以查看《寫會(huì)MySQL索引》一文進(jìn)行查看！唉，我就吃過不少?zèng)]加索引或忘記添加索引的虧，記憶猶新?。?！
小結(jié)
以上是我數(shù)據(jù)庫設(shè)計(jì)表時(shí)躺過的坑，下面小結(jié)精簡版本一下:
- 允許保存表情的表，存儲(chǔ)格式設(shè)計(jì)為utf8mb4，避免使用utf8。
- 選擇合適的數(shù)據(jù)類型。
- 主外鍵字段類型一定要一致，否則會(huì)造成隱式轉(zhuǎn)化，不走索引，造成生產(chǎn)事故！
- 表以及字段上添加合理的注釋。
- 數(shù)據(jù)庫表設(shè)計(jì)時(shí)，一定要在外鍵字段以及合適的字段上加索引。
上面是我數(shù)據(jù)庫表設(shè)計(jì)時(shí)，遇到踩過坑以后的經(jīng)驗(yàn)之談。有些坑當(dāng)時(shí)還真花了不少時(shí)間來填補(bǔ)。記錄在這里，如果能幫助到你，那就太好了！
