序有朋友在后台留言。希望能说说我在设计数据库表时踩过的坑。那么，今天就来说说我在设计数据库表时踩过的坑，以及对现在数据库表设计的一些建议。希望能帮到你。utf8pot场景：在给客户搭建微信小店的时候，需要保存微信的授权信息。这时候，就有了昵称字段。设计数据表的时候下意识的把表的存储格式设置为utf8，生产上线一段时间偶尔会出现save异常。经分析，异常原因是：用户昵称中有邮件表情。无法存储utf8格式的数据表。经验提示：在设计数??据表时，一定要注意该字段存储的内容。如果允许设置表达式，则一定不能使用utf8，而要使用utf8mb4。选择正确的类型在设计数据库表时，字段的类型确实很难设计。这里简单介绍一下：对于存储手机号的字段，varchar(20)就够了，不应该设计成varchar(100)。设置为varchar(100)只会消耗更多的存储和内存开销，得不偿失！要省Boolean类型，用tinyint就够了，不用设计成int甚至bigint。如果数据类型设计的太大，会造成不必要的浪费（磁盘、内存、CPU），最重要的是，这是吃力不讨好的事。主键和外键字段类型不一致。主键和外键字段类型不一致。说起来你可能不相信，但是在设计数据库表的时候，一不小心，不一致就会埋下隐式类型转换的坑。如下：User表：createtablet_base_user(oidbigint(20)notnullprimarykeyauto_incrementcomment"primarykey",....)注意此时的主键oid为bigint(20)。用户地址表：createtablet_base_user_address(oidbigint(20)notnullprimarykeyauto_incrementcomment"primarykey",user_idvarchar(30)nullcomment"userid".....)你看，t_base_user_address表中的user_id外键字段在设计时是varchar(30).你可能认为自己不可能犯这样的错误，说出来也不怕开玩笑。这样的坑我踩过好几次了，等到最后发现SQL慢的时候才发现自己掉进了这样的陷阱！！！注释在设计数据库表之前，没有添加注释的习惯。直接的后果是：一旦数据库设计阶段结束，在后续使用数据表时就会猜测字段名。我们在写代码的时候就知道注解很重要，在设计数据库表的时候注解也很重要！一定要记得添加注释，无论是表、字段还是索引，都必须添加注释。如：createtablet_base_user(oidbigint(20)notnullprimarykeyauto_incrementcomment"primarykey",....)给已有表添加注释altertablet_base_usermodifyoidbigint(20)notnullprimarykeyauto_incrementcomment"primarykey";添加注释时，还需要注意：在一些需要计算的字段上，需要添加计算规则文档的链接。方便以后查找！添加索引在之前的文章中也有提到。一个好的数据表设计，一开始就应该考虑添加索引。这个阶段添加索引的成本不仅低。并且不会留下查询慢甚至生产事故的隐患！如何添加索引，索引重要与否，可以查看文章《写会MySQL索引》！唉，不加索引或者忘记加索引，让我吃了不少苦头，到现在还记得！！！总结以上就是我在设计数据库表的时候埋下的坑。这里总结一下简化版：允许保存表达式的表，存储格式设计为utf8mb4，避免了utf8。选择合适的数据类型。主外键字段类型必须一致，否则会造成隐式转换，不使用索引，造成生产事故！为表格和字段添加合理的注解。在设计数据库表时，一定要为外键字段和合适的字段添加索引。以上就是我在数据库表设计中遇到坑后的心得。有些坑真的花了很多时间才填上。记录到这里，如果能帮到你，那就太好了！
