建站
咨詢
售后
建站咨詢
新聞中心
前言
站在用戶的角度思考問題，與客戶深入溝通，找到貢覺網(wǎng)站設(shè)計與貢覺網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗，讓設(shè)計與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個性化、用戶體驗好的作品，建站類型包括：成都網(wǎng)站設(shè)計、成都網(wǎng)站建設(shè)、外貿(mào)網(wǎng)站建設(shè)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣、域名注冊、網(wǎng)絡(luò)空間、企業(yè)郵箱。業(yè)務(wù)覆蓋貢覺地區(qū)。
有朋友在后臺留言。希望我能說說我在數(shù)據(jù)庫表設(shè)計時踩過的坑。那么，我們今天就來聊聊我在數(shù)據(jù)庫表設(shè)計時踩過的坑，以及現(xiàn)在對數(shù)據(jù)庫表設(shè)計的一點建議。希望能夠幫助到你。
utf8的鍋
場景 : 之前在給客戶做微商城時，需要保存微信的授權(quán)信息，此時就有一個nickname字段，在設(shè)計數(shù)據(jù)表時，潛意識的將表的存儲格式設(shè)置為utf8，生產(chǎn)上線一段時間后偶爾出現(xiàn)保存異常。經(jīng)分析，出現(xiàn)異常的原因是：用戶nickname中有email表情符號。utf8格式的數(shù)據(jù)表存儲不下導(dǎo)致。
經(jīng)驗提示： 在設(shè)計數(shù)據(jù)表時，一定要注意該字段存儲的內(nèi)容，如果允許設(shè)置表情，則一定不能使用utf8，而是使用utf8mb4。
選擇合適的類型
在數(shù)據(jù)庫表設(shè)計時，字段的類型還真不好設(shè)計，這里簡單說說：
- 保存手機號的字段，用varchar(20)就已經(jīng)足夠了，就不應(yīng)該設(shè)計為varchar(100)，設(shè)置為varchar(100)只會消耗更多的存儲以及內(nèi)存開銷，得不償失??！
- 保存Boolean類型，使用tinyint就夠了，而不需要設(shè)計為int，甚至bigint。
數(shù)據(jù)類型設(shè)計的過大,就會造成沒必要的浪費（磁盤，內(nèi)存,CPU），最主要的是，這是一件費力不討好的事情。
主外鍵字段類型不一致
主外鍵類型不一致，說起來，你可能會不相信，但在數(shù)據(jù)庫表設(shè)計時，稍不留神，就不一致，埋下隱式類型轉(zhuǎn)換的坑。如下:
用戶表:
- create table t_base_user(
- oid bigint(20) not null primary key auto_increment comment "主鍵", ....
- )
注意此時的主鍵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" ....
- )
你看，此時在t_base_user_address表中的user_id外鍵字段,設(shè)計時的卻是varchar(30)。你可能覺得你不可能發(fā)生這樣的錯誤，說出來也不怕你笑話，我就踩過好幾次這樣的坑，到***發(fā)現(xiàn)慢SQL了，才發(fā)現(xiàn)自己中了這樣的坑?。?！
注釋
之前在數(shù)據(jù)庫表設(shè)計時，就沒有加注釋的習(xí)慣，造成的直接后果是：數(shù)據(jù)庫設(shè)計階段一過，后續(xù)數(shù)據(jù)表的使用中，字段名就全靠猜了。我們寫代碼是知道注釋是非常重要的，同樣在設(shè)計數(shù)據(jù)庫表時，注釋也非常重要！一定要記住加注釋，無論是表，還是字段，索引，都必須加上注釋。
如:
- 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 "主鍵"；
加注釋時，還要注意的是：在一些需要計算的字段上，需要加上計算規(guī)則文檔的鏈接。方便后續(xù)查找！
加索引
在之前的文章中也有說過，一個好的數(shù)據(jù)表設(shè)計，在一開始就應(yīng)該考慮添加索引，這個階段添加索引成本不僅***。而且還不給后續(xù)留下慢查詢，甚至生產(chǎn)事故的隱患！索引怎么加，索引重不重要，可以查看《寫會MySQL索引》一文進行查看！唉，我就吃過不少沒加索引或忘記添加索引的虧，記憶猶新?。?！
小結(jié)
以上是我數(shù)據(jù)庫設(shè)計表時躺過的坑，下面小結(jié)精簡版本一下:
- 允許保存表情的表，存儲格式設(shè)計為utf8mb4，避免使用utf8。
- 選擇合適的數(shù)據(jù)類型。
- 主外鍵字段類型一定要一致，否則會造成隱式轉(zhuǎn)化，不走索引，造成生產(chǎn)事故！
- 表以及字段上添加合理的注釋。
- 數(shù)據(jù)庫表設(shè)計時，一定要在外鍵字段以及合適的字段上加索引。
上面是我數(shù)據(jù)庫表設(shè)計時，遇到踩過坑以后的經(jīng)驗之談。有些坑當(dāng)時還真花了不少時間來填補。記錄在這里，如果能幫助到你，那就太好了！
標(biāo)題名稱：MySQL表設(shè)計時踩過的坑！
文章網(wǎng)址：http://m.5511xx.com/article/ccehgei.html
