前言

一位朋友正在后台留言。我希望我能谈谈在设计数据库表时我踩到的坑。那么，让我们谈谈我在设计数据库表时遇到的问题，现在我对数据库表设计提出了一些建议。我希望能帮助你。

　　utf8的锅

在场景:之前，当您为客户进行微购时，您需要保存微信的授权信息。这时，有一个昵称字段。在设计数据表时，表的存储格式下意识地设置为utf8，并且偶尔在生产上线一段时间后出现。保存例外。经过分析，异常的原因是：用户昵称有一个电子邮件表情符号。不会产生utf8格式数据表存储。

经验提示：在设计数​​据表时，请务必注意字段中存储的内容。如果允许设置表达式，则不能使用utf8，而是使用utf8mb4。

选择合适的类型

在数据库表的设计中，字段的类型确实不是很好的设计，这里有一个简单的陈述：

保存电话号码的字段，使用varchar（20）就足够了，它不应该设计为varchar（100），设置为varchar（100）只会消耗更多的存储和内存开销，不值得损失！

保存布尔类型，使用tinyint就足够了，无需设计int，甚至bigint。

如果数据类型设计得太大，则会造成不必要的浪费（磁盘，内存，CPU）。最重要的是，这是一项吃力不讨好的任务。

　主外键字段类型不一致

主要外键类型不一致。说到它，你可能不相信它，但在设计数据库表时，它是不显眼和不一致的，并埋没了隐式类型转换的坑。如下:

用户表:

创建表t_base_user（

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

）

注意，此时的主键oid是bigint（20）。

用户地址表：

创建表t_base_user_address（

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

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

）

您看，此时t_base_user_address表中的user_id外键字段在设计时是varchar（30）。你可能觉得你不能犯这样的错误。如果你说，你不怕笑话。我已多次踩过这样的坑。当我发现慢速SQL时，我发现自己陷入了这样的困境！ ！ ！

　注释

在数据库表设计之前，没有添加注释的习惯，直接后果是：一旦数据库设计阶段，使用后续数据表，字段名称都是猜测。我们编写代码以了解注释非常重要，并且在设计数据库表时注释也非常重要！一定要记得添加注释，无论是表，还是字段，索引，都必须添加注释。

如:

创建表t_base_user（

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

）

已添加现有注释

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

添加注释时，还需要注意的是，在某些需要计算的字段上，需要添加指向计算规则文档的链接。方便后续搜索！

　加索引

如前一篇文章所述，良好的数据表设计应考虑在开头添加索引。在这个阶段添加索引的成本不仅是最低的。并且仍然不要对后续行动，甚至生产事故的隐患进行缓慢的查询！如何添加索引，索引并不重要，可以查看《写会MySQL索引》文章查看！嘿，我没有索引或忘记添加索引就吃掉了很多损失。记忆仍然新鲜！ ！ ！

　小结

以上是我设计桌子时所处的坑。以下是简化版本:

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

选择正确的数据类型。

主外键字段类型必须一致，否则会导致隐式转换，不去索引，导致生产事故！

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

设计数据库表时，请务必在外键字段和相应字段中添加索引。

以上是我遇到踩踏坑经验后数据库表设计的经验。有些坑真的花了很多时间来填补。在这里记录，如果它可以帮助你，那将是伟大的！

« Piggy CMS智能餐厅：餐饮O2O行业解决方案 | 扎克伯格的家人欢迎第二个孩子。这位亿万富翁仍然想要另一个妓女 »