MySQL表设计时踩过的坑!
2018-01-11 09:23:00  站长网   [查看原文]

A5创业网

项目发布

申请报道

扫一扫,联系编辑获得审核机会

符合以下要求,获得报道机会

1. 新公司求报道

2. 好项目求报道

3. 服务商求报道

4. 投资融资爆料

中介交易 网站交易 域名交易 公众号

登录 注册

会员中心 退出

微信

微博

手机版

网站导航

找项目 找服务

客服热线:400-995-7855

创业

创业动态 投资融资 创业故事 众创空间

财税

工商注册 公司财税 资质办理

产权

商标 版权 专利

科技

互联网 IT业界 移动 八卦休闲

站长

网站运营 建站经验 SEO 交互设计 好站推荐

营销

营销策划 网络推广 移动营销

电商

电商资讯 电商分析 移动电商

IDC

IDC报告 云计算 服务器 安全 CDN

更多

自媒体 公众号 小程序 产品 域名 会议 数码 游戏 系统 技术

首页

创业

创业项目

科技

站长

产品

营销

电商

域名

会议

A5交易

A5营销

创业服务

当前位置:首页 > 站长 > 交互设计 > 正文 品牌

标签

专题

软文

MySQL表设计时踩过的坑! 2018-01-11 09:23 来源:数据库开发 我来投稿 我要评论

创业项目优选 好项目来A5招商 ,点击入驻!

前言

有朋友在后台留言。希望我能说说我在数据库表设计时踩过的坑。那么,我们今天就来聊聊我在数据库表设计时踩过的坑,以及现在对数据库表设计的一点建议。希望能够帮助到你。

utf8的锅

场景 : 之前在给客户做微商城时,需要保存微信的授权信息,此时就有一个nickname字段,在设计数据表时,潜意识的将表的存储格式设置为utf8,生产上线一段时间后偶尔出现保存异常。经分析,出现异常的原因是:用户nickname中有email表情符号。utf8格式的数据表存储不下导致。

经验提示: 在设计数据表时,一定要注意该字段存储的内容,如果允许设置表情,则一定不能使用utf8,而是使用utf8mb4。

选择合适的类型

在数据库表设计时,字段的类型还真不好设计,这里简单说说:

保存手机号的字段,用varchar(20)就已经足够了,就不应该设计为varchar(100),设置为varchar(100)只会消耗更多的存储以及内存开销,得不偿失啊!

保存Boolean类型,使用tinyint就够了,而不需要设计为int,甚至bigint。

数据类型设计的过大,就会造成没必要的浪费(磁盘,内存,CPU),最主要的是,这是一件费力不讨好的事情。

主外键字段类型不一致

主外键类型不一致,说起来,你可能会不相信,但在数据库表设计时,稍不留神,就不一致,埋下隐式类型转换的坑。如下:

用户表:

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外键字段,设计时的却是varchar(30)。你可能觉得你不可能发生这样的错误,说出来也不怕你笑话,我就踩过好几次这样的坑,到最后发现慢SQL了,才发现自己中了这样的坑!!!

注释

之前在数据库表设计时,就没有加注释的习惯,造成的直接后果是:数据库设计阶段一过,后续数据表的使用中,字段名就全靠猜了。我们写代码是知道注释是非常重要的,同样在设计数据库表时,注释也非常重要!一定要记住加注释,无论是表,还是字段,索引,都必须加上注释。

如:

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 "主键";

加注释时,还要注意的是:在一些需要计算的字段上,需要加上计算规则文档的链接。方便后续查找!

加索引

在之前的文章中也有说过,一个好的数据表设计,在一开始就应该考虑添加索引,这个阶段添加索引成本不仅最低。而且还不给后续留下慢查询,甚至生产事故的隐患!索引怎么加,索引重不重要,可以查看《写会MySQL索引》一文进行查看!唉,我就吃过不少没加索引或忘记添加索引的亏,记忆犹新!!!

小结

以上是我数据库设计表时躺过的坑,下面小结精简版本一下:

允许保存表情的表,存储格式设计为utf8mb4,避免使用utf8。

选择合适的数据类型。

主外键字段类型一定要一致,否则会造成隐式转化,不走索引,造成生产事故!

表以及字段上添加合理的注释。

数据库表设计时,一定要在外键字段以及合适的字段上加索引。

上面是我数据库表设计时,遇到踩过坑以后的经验之谈。有些坑当时还真花了不少时间来填补。记录在这里,如果能帮助到你,那就太好了!

本栏目中的所有页面均系自动生成,自动分类排列,采用联索网络信息采集、网页信息提取、语义计算等智能搜索技术。内容源于公开的媒体报道,包括但不限于新闻网站、电子报刊、行业门户、客户网站等。使用本栏目前必读