其实闭着眼睛打造手表的18 条包罗万象的规则的问题并不复杂，但是又很多的朋友都不太了解，因此呢，今天小编就来为大家分享闭着眼睛打造手表的18 条包罗万象的规则的一些知识，希望可以帮助到大家，下面我们一起来看看这个问题的分析吧！

新的需求也意味着新的设计。原来的桌子设计不能满足新的需求，所以需要设计一张桌子。

1、命名

1.1、字段命名

中国人的命名习惯是中式英语，所以在命名时，每个人都有自己的特点。设计表格时尽量统一，要么全中文拼音，要么全英文。记住不要将它们混合在一起会很不舒服。

给表和字段起一个好的名字非常重要。最好是看到名字就知道意思了。

推荐一个命名网站，如果没有就去ChatGPT创建一个名字。

https://unbug.github.io/codelf/

以用户名为例：

正面例子：

用户名： 用户名反例：

用户名：yong_hu_name、name等。需要注意的是，最好知道名字的含义，记住名字不要太长。

说完名字，我们来谈谈大小写。

1.2、大小写

国内数据库中，有些会默认全大写，而有些小写则不兼容，可能会导致bug。从视觉上看，小写加下划线的形式更具可读性和直观性，因此命名时保留同一句话，统一规则。

要么全部大写并带下划线，要么全部小写并带下划线。禁止混合使用大写和小写。

建议使用所有小写和带下划线的格式。

混合大小写的字符被删除并进行审查。

正面例子：

产品名称：product_name, PRODUCT_NAME 反例：

产品名称：product_NAME、PRODUCT_name

1.3、分隔符

在命名字段时，很多场景下单个单词无法满足我们的命名需求。那么如何连接多个单词呢？

建议使用_下划线进行连接。

还有驼峰形式或无连接器的形式，这是被禁止的。有些框架在使用驼峰式大小写时会遇到转换问题。

使用连接器的可读性太差。谁能一眼读懂一长串？

正面例子：

产品名称：product_name, PRODUCT_NAME 反例：

产品名称：productname、productName、product@name

1.4、关键字

上面说了，名称要以名称为主，但也要避免与数据库中的关键字冲突，比如工作中经常用到的状态等。

例如，如果涉及到关键词，可以按照业务来区分。

创建时间：create_time 更新时间：update_time 删除状态：delete_status，已删除

1.5、索引名

索引的命名是按照索引的类型来分类的，因为索引的类型有很多种，主键、唯一、普通、联合、空间等。

通过索引名称，一眼就能看出是普通索引、唯一索引还是联合索引。然后对指标的名称进行标准化。

例如，联合索引按照字段顺序命名，唯一索引则添加前缀uniq。

1.6、表名

讲完了字段的相关名称，还有提到表名。在表的命名中，除了体现当前表的含义外，最好加上业务前缀。

例如，与订单相关的表使用order_ 前缀。

2、字段类型

字段类型选择太多。对于时间类型，我们可以使用date、datetime、timestamp、bigint等。

字符类型包括varchar、char、text等。数字包括int、bigint、tinyint、smallint等。

事实上，很多事情都令人困惑。我不知道该用哪一个。最好使用varchar。这就是你所做的吗？

如何选择合适的字段类型成为我们不得不考虑的问题。

例如，对于状态值，对于10以内的数字，每个数字1个字节就足够了。只需使用tinyint即可。如果选择bigint，就会浪费空间。

所以我们可以参考以下原则：

1、在满足业务需求时，选择占用存储空间尽可能小的字段类型。

2、如果字段长度固定，可以选择char，如果字段长度不固定，可以选择varchar。

3. 该true或false字段是否可以使用bit类型。

4. 枚举字段可以是tinyint类型。

5、主键使用bigint类型。

6、金额字段可以使用小数或换算单位存储bigint。

7、时间字段使用datetime或者timestamp或者将timestamp转换成bigint保存。

3、字段长度

长度在上面字段类型选择中提到。接下来我们重点关注长度的选择。

varchar(255)中的255表示字符长度。在MySQL中，除了varchar和char代表字符长度外，其他类型都是字节长度。

bigint的实际长度是8个字节。 bigint(4)表示小于4字节时，前面补0（前提是开启自动填充）。

当超过4字节时，根据实际情况显示。

比如当前数据是12345，显示的时候也显示12345。

不过需要注意的是，有些MySQL客户端只会显示4个字节，比如1234，所以bigint(4)中的4代表显示的长度，实际占用的仍然是8个字节。

4、字段个数

在看数据库表优化的时候应该经常听到的就是减少表中的字段数，防止出现宽表。

所以我们建表的时候最好控制字段的数量。我上一个单位涉及到的业务类型表，字段数量确实非常多。对于这种场景，我们可以将大表拆分成小表，每个表都有一个共同的唯一ID作为主键来关联。

建议每个表的字段数量控制在20个。如果字段过多，表中存储的数据量较大，会严重影响查询效率。

5、主键

不知道您是否遇到过这种情况。我遇到过甚至没有主键的表。都是普通的列，更不用说索引了。

之所以每个表都需要有主键，是因为与其他索引相比，主键索引可以避免查询时的表备份，提高查询效率。而且主键索引也是唯一索引，可以作为业务去重。

在单个数据库中只要使用默认的自增ID作为主键，效率还是很高的。在分布式环境中，最好采用增量分布式ID算法来保证全局唯一性。

需要注意的是，建议为主键保存与业务无关的值，以方便后期扩展。

关于分布式ID生成算法，可以阅读之前的这篇文章：全网最全面的分布式ID分析

6、外键

说完了主键，我们来说说外键。避免使用这个。

说实话，用起来并不容易。外键最初的作用是保证数据的一致性。当相关表很少时，就没用了。当关联表数量增多时，执行删除等操作时性能非常差。

除了外键之外，还有触发器和存储过程。每次在开源框架中看到这些我就头疼。

7、索引

表的主键索引是必要的。对于其他索引，您可以根据自己的业务场景添加。但是，表中的索引数量不宜过多。建议单表索引数量不要超过5个。

创建索引时，尽可能考虑索引覆盖、最左前缀、索引下推等优化方案。我已经把链接放在下面了，给那些还不明白的人。

MySQL索引（二）常见的索引优化方案有哪些？

MySQL索引(1)

需要注意的是，不建议为高度重复的字段创建索引，因为没有意义。

8、唯一索引

这里为什么单独提取唯一索引？还是因为有陷阱？当你使用唯一索引时，如果它是单个字段就可以了。如果是多个字段的话就一定要注意了。如果出现空值，则唯一性约束可能会变得无效。唯一索引的陷阱将在下一篇文章中单独讨论。

9、NOT NULL

建议设计表时，可以保证不会出现NULL值的列设置为NOT NULL。这是因为当存储引擎为Innodb时，NULL值会占用较多的空间，查询时也会使用NULL值。会导致索引失败，查询条件只能通过IS NULL或IS NOT NULL来判断。

因此，如果可以定义为NOT NULL，建议定义为NOT NULL。

将其定义为NOT NULL 也有优点。如果INSERT时漏掉了某个字段的值，会直接报错提醒。多么明显的错误啊。

另一种情况是向现有表添加字段。此时历史数据中新添加的字段是没有值的，因为设置为NOT NULL的字段应该尽可能分配一个默认值。

10、存储引擎

这个应该没什么好说的。大多数都使用Innodb。如果没有的话，就去检查一下，然后更改一下。如果你的业务场景适合其他引擎或者你有自己开发的引擎，则忽略即可。

如果你不知道为什么使用Innodb，现在你知道了，因为Innodb支持事务并且它的性能越来越好。

11、时间字段

以下是对数据库中各个容易出现错误的字段类型的分析。

第一个是时间字段。毕竟时间类型太多了。我们可以使用date、datetime、timestamp、varchar、bigint等来存储时间。

保存varchar的好处是方便读取，直接返回给前端，不需要转换。

date只能保存日期，不能保存时间，看需要。

datetime和timestamp更适合我们节省时间，但也有区别。

datetime

datetime 存储更广泛的时间范围。在MySQL中，它可以表示从1000-01-01到9999-12-31的日期和时间。 datetime不涉及时区转换。 datetime不支持自动更新。

timestamp

时间戳的存储范围较窄。在MySQL中，它可以表示从1970-01-01 00:00:00 UTC到2038-01-19 03:14:07 UTC的日期和时间。时间戳通常采用UTC存储，因此需要进行时区转换，更适合跨时区存储数据。 timestamp 在MySQL中，还可以设置更新时间字段，设置为自动更新。需要注意的是，设置时间默认值时，不要设置0000-00-00 00:00:00，防止查询时时间转换错误。

除了上述之外，还可以使用bigint来存储时间戳。除了可读性和需要转换之外，似乎没有什么大问题。你用过这种方法来存储时间吗？

12、金额字段

想到的金额字段就是浮点类型float、double、decimal等。

float 和double 会失去精度，所以不要使用它们。因此，建议您使用十进制。但是，使用小数时需要注意几个陷阱。如果您还不理解它们也没关系。我会把链接放在下面。

不掌握四大陷阱你还敢用BigDecimal吗？

如果你仍然不想使用十进制，那么我建议你将其转换为美分或更小的货币单位并使用bigint存储。

13、json字段

这个字段一直是我不想使用的，因为它不兼容。如果后面需要切换数据库，如果你切换的数据库不支持json类型，那么恭喜你，改一下代码就可以了。

这个时期有新的需求。我尝试了这个json字段，发现它很好用，只要它兼容json格式。

不好的是处理和查询数据仍然不太方便。

总之，如果可以的话，就不应该使用它。建议json类型直接存储varchar，然后在代码中转换一下比较好。毕竟不需要考虑兼容性问题。

14、大字段

如果使用json，难免会有大字段的可能。大字段的定义是占用大量存储空间的字段。

如果直接将大文本定义为文本类型，可能会浪费存储空间。如果业务可以对字段进行最大长度限制，那么我们可以使用varchar类型进行存储，效率更高。

另一种类型是blob，它直接存储文件内容。如果你也做同样的事情，我建议你改变它。这个设计有点不合理。

把一个文件地址保存在最后的存储中该多好啊。

15、冗余字段

在设计表时，为了查询性能，某些信息字段可能是冗余的。例如，一个表需要记录用户的userId。当我们需要用户名时，还需要通过userId进行相关查询。获取用户名，然后我们可以将多余的用户名添加到我们的表中以提高我们的查询效率。

相当于用空间换时间的概念。以这个空间为代价，减少了join查询的时间，这对于提高查询性能很有帮助。

我们不能只谈论好的部分，但也有不好的部分。有存储就必然有维护，很容易造成数据不一致。

因此，在使用时，您还应该根据对您业务的综合评估，选择更适合您业务的方法。

16、注释

表注释和字段注释与代码开发中的代码注释没有什么区别。它们必须写清楚。如果是状态值1、2、3、4、5，如果你很久不写评论了，你知道它是什么吗？你的意思是？

需要注意的一点是，你写的注释必须与代码中的注释同步。不要忘记最后一个字段有很多含义。最后，你无法分辨哪个意味着什么。这可不是什么好事。

17、字符集

说了这么多表里的东西，我们来说说底层最基本的编码。 MySQL支持的编码类型还是很多的，不过这里建议使用utf8mb4，因为utf8无法存储emoji表情，所以被取代是一种趋势。使用ut8mb4可以省去很多麻烦。

常用的gbk、utf8、utf8mb4的区别如下：

gbk包含GB2312标准中的所有字符，不支持Unicode标准，因此只能在中国使用，在处理多种语言时能力有限。 UTF8是一种变长的Unicode编码方式，具有良好的兼容性。它是一种广泛使用的标准，支持多种语言。缺点是不支持emoji表情。 utf8mb4是utf8的扩展，也是MySQL中推荐的字符集，特别是支持表情符号和特殊字符。

18、排序规则

上面提到了字符集，排序规则和字符集也是密切相关的。在mysql中，如果你的字符集设置为utf8mb4，那么你的排序规则也是以utf8mb4开头。常用的是utf8mb4_general_ci和utf8mb4_bin。

utf8mb4_general_ci 的排序规则不区分大小写。简单来说，如果a等于A，就会认为它们是相同的字符。 utf8mb4_bin 区分大小写，a 和A 将被视为不同的字符。所以，排序规则还是需要根据我们的业务场景来选择，比如用户的登录密码。

总结

表的字符集和排序规则是统一的，您可以根据业务需求选择合适的编码。

命名时要注意含义，无论是表名、字段名还是索引名，命名规则都要统一。

字段方面，控制表字段数量，防止产生宽表。在字段类型满足业务的前提下，选择占用存储空间较小的字段，避免产生大字段。您可以使用冗余字段来加快查询速度。对于那些不了解类型的人来说，类型很少使用或根本不使用。

关于索引，每个表必须有一个主键索引，其次使用唯一索引时要注意避免陷阱。

用户评论

酒笙倾凉

这篇文章真的太棒了！我本来对闭眼建表这件事一头雾水，看了你的文章，感觉终于开窍了。这些军规虽然听着很严格，但确实能提高效率，关键是要坚持执行！

    有13位网友表示赞同！

_心抽搐到严重畸形っ°

作为一名资深程序员，对于高效开发尤为重视，这篇“闭眼建表”的18条军规总结得非常到位！我尤其赞赏你“预想用户需求”和“数据结构设计”这两点，这确实决定了表格的最终质量。

    有20位网友表示赞同！

败类

感觉这些军规过于严格了吧？程序开发不应该那么死板吗？要考虑灵活性和迭代性。闭眼建表听起来有点像是在强迫自己走一条固定的道路，我觉得不如保持一个开放的心态去探索更合适的方案。

    有6位网友表示赞同！

花海

这篇文章很有启发意义，让我对闭眼建表的流程有了更清晰的理解。这些军规帮助我明确了开发方向，避免了许多不必要的复杂操作。不过，实际应用中，还需要根据具体情况进行调整和修改。

    有11位网友表示赞同！

屌国女农

我之前从来没想过“闭眼建表”，原来是一种非常有效的开发方式！这篇博文很好的将18条军规展现出来，让我感觉像是学习了一套全新的技能，以后可以尝试着应用到实际项目中去

    有10位网友表示赞同！

青袂婉约

有些军规我觉得很有必要，比如数据类型选择要慎重啊，不然后期修改超难受的。还有规范命名也是很重要的一点，毕竟代码的可维护性非常重要。

    有14位网友表示赞同！

(り。薆情海

这篇文章写的有点太理论化了，缺乏一些实践经验分享。实际开发中，这些军规并不是绝对的硬规矩，需要根据具体项目情况灵活处理，才能真正提升开发效率

    有19位网友表示赞同！

不识爱人心

标题吸引了我，我一直在想怎么提高建表效率，结果还真有这种方法！不过我觉得 “闭眼”有点夸张吧？还是需要有一定的数据和需求分析基础。

    有8位网友表示赞同！

冷月花魂

感觉“军规”这两个词用得有点太严苛了，其实是在提倡一种开发规范，希望程序员们能够更加理性地看待数据库设计，而不是简单的拼凑一个表格

    有12位网友表示赞同！

优雅的叶子

我曾经也遇到过闭眼建表的场景，但是因为缺乏经验和指导性方法论，最终造成了数据混乱、难以维护的问题。这篇博文很有用，让我明白了应该如何有效地进行闭眼建表操作。

    有15位网友表示赞同！

情深至命

"闭眼" 建表格听起来就有点吓人啊，感觉风险很大，一旦出错就需要大规模修复，太耗时间了！还是要踏实一点，仔细分析需求再开始设计表格结构吧。

    有11位网友表示赞同！

单身i

这篇文章介绍的“闭眼建表”方法很有意思，如果能掌握这种技巧，确实可以提高开发效率。但最重要的是要有一个良好的数据库设计理念，而不是仅仅依靠这些军规就能够保证高质量的代码。

    有8位网友表示赞同！

ˉ夨落旳尐孩。

作为一个对技术要求很高的程序员来说，我认为“闭眼建表”是一种非常危险的做法，很容易导致数据不完善、逻辑混乱等问题。 建议大家还是要认真分析需求，制定合理的数据库设计方案。

    有7位网友表示赞同！

忘故

这些军规的很多点都说的很好，比如要根据用户需求明确表格结构，避免冗余和重复字段等等。但是我觉得在"闭眼建表"的实践中，也要注重实际项目的复杂度，不要太过死板地遵循所有规则。

    有18位网友表示赞同！

迁心

闭眼建表？这个概念太吓人了！感觉这样很容易做出错误的表格设计。还是认真分析需求，再一步步构建表格，这样才能确保数据的一致性和完整性。

    有13位网友表示赞同！

全网暗恋者

其实"闭眼建表"更像是一种熟能生巧的状态，需要不断地练习和积累经验。当然，这些军规能够提供一个很好的框架和指引，但最终还是要靠自身的实践能力来掌握

    有10位网友表示赞同！

把孤独喂饱

这篇文章的内容很实用，可以帮助初学者快速了解“闭眼建表”的概念和流程。但是我觉得"闭眼" 建表的难度还是蛮大的，需要一定程度的编程经验和数据库设计知识才能够有效地运用到实际开发中。

    有11位网友表示赞同！