关于数据库:设计表时如何选择正确的数据类型

设计表时，如何抉择正确的数据类型

前言

假如当初有一个需要，须要创立一张 orders 表来存储客户的订单信息。假如表构造如下:

CREATE TABLE orders (
  order_id INT AUTO_INCREMENT PRIMARY KEY, -- 订单 ID，主键，自增
  customer_id INT NOT NULL,                -- 客户 ID，假如已在其余表中定义
  order_date DATETIME NOT NULL,            -- 订单日期和工夫
  total_amount DECIMAL(10, 2) NOT NULL,    -- 订单总金额，保留两位小数
);

这里须要设计一个 status 字段，用来示意订单的以后状态。订单状态能够是以下几种：待领取、已领取、发货中、已实现、已勾销。

这个 status 字段在业务逻辑中十分重要，因为它会频繁地用于查问，更新等，不便用户查看本人处于不同状态的订单。

此时咱们应该好好设计该字段，在保障其满足根本业务需要的同时，性能和扩展性这些方面也要充分考虑，防止之后较大的保护老本以及性能开销。

回到这个字段的设计来说，当初咱们就有几种不同的数据类型抉择来存储这个 status 字段，而且也可能根本得满足业务要求，比方VARCHAR 类型，ENUM 类型，TINYINT 类型，具体设计如下:

• VARCHAR

咱们能够抉择应用字符串类型 VARCHAR 来间接存储状态文本（如 ” 待领取 ”、” 已领取 ” 等）。

• ENUM

咱们能够应用枚举类型 ENUM(‘ 待领取 ’, ‘ 已领取 ’, ‘ 发货中 ’, ‘ 已实现 ’, ‘ 已勾销 ’)来存储这些状态。

• TINYINT

咱们能够抉择应用较小的整数类型 TINYINT，并为每种状态调配一个数字代码(如 1 = 待领取，2= 已领取等）。

这种状况下，status 字段时应该应用VARCHAR，ENUM 还是TINYINT 类型呢?

在平时开发设计时，咱们总是不可避免说会遇到相似这种抉择。这种状况下咱们应该怎么抉择呢? 能从哪些方面思考呢？

数据类型抉择的准则

在 MySQL 数据表设计时，抉择适合的数据类型对于进步 数据库 的性能是至关重要且根底的。上面介绍一些简略的准则，帮忙咱们在遇到抉择时，能过做出更好的抉择。

更小的更好

抉择可能在满足需要的前提下，占用最小存储空间的数据类型。

在执行查问和其余操作时会将数据加载到内存中，应用较小的数据类型能够缩小内存应用，从而容许更多的数据同时驻留在内存中，进步数据的处理速度。同时它们占用更少的磁盘、CPU 缓存，并且解决时须要的 CPU 周期也更少。

同时，数据类型的大小也会对索引的性能产生影响。较小的数据类型也能够进步索引的效率，字段占据空间越小，该字段对应的索引更小，能够进步索引的查找速度并缩小磁盘 I / O 操作。这对查问性能有显著影响，尤其是对于大量数据和高负载的零碎来说。

举例来说，如果你晓得一个字段的值不会超过 255，那么应用 TINYINT 而不是 INT，这个不论是在存储空间还是查问效率上来说，都是 TINYINT 的性能更好。

然而要确保 没有低估须要存储的值的范畴，因为扩大数据类型的范畴是一个十分耗时和苦楚的操作，也升高了零碎的可维护性和扩展性，这样子就得失相当了。

优先应用内建类型

在数据库设计中，应该优先应用数据库的内置类型的示意，而不是一些通用类型。

优先应用数据库内建类型有以下益处:

性能方面，数据库都会对内建数据类型进行了优化，以提供更好的存储和检索性能。例如，内建的数值和日期类型通常比通用的字符串类型在索引、排序和比拟操作中体现得更好。

数据完整性方面，内建数据类型通常包含数据验证性能，能够在数据插入或更新时主动进行类型查看。这有助于避免有效数据的输出，从而保护数据的一致性和准确性。举例来说，DATE 类型的字段将主动回绝任何不合乎日期格局的数据。

具备更高的存储效率。因为它们是针对所存储数据的性质量身定做的。例如，整数类型（如 INT 或 BIGINT）通常比等效的字符串示意（如数字的文本模式）占用更少的存储空间。

简化查问。内建数据类型能够简化查问语句的编写，因为它们不须要额定的转换或格式化函数。例如，应用 DATE 类型能够间接比拟日期，而不须要将字符串转换为日期。

因而，在数据库设计中，咱们应该优先应用零碎内建的数据类型，只有在内建字段不满足需要的状况下，才思考一些通用数据类型来示意。

优先应用简略类型

简略和简单数据类型的界定并没有一个严格的规范，这些术语更多地是绝对的，并且取决于上下文。

这里的简略和简单是绝对于操作和解决这些数据类型所需的资源来说的。

当咱们说简略类型时，咱们通常是指这些类型在数据库中的解决更加间接和高效。而简单类型则可能须要更多的解决步骤，更多的资源，或者更简单的外部示意。

当咱们在数据库设计时，某个字段类型有多种抉择，那么其中须要更多的存储空间，查问排序等操作更为简单，性能更为低下的，此时该字段类型在该场景下就被界定为简单类型。

这里举个例子阐明一下，假如咱们在用户信息表中有一个字段用于存储性别。性别通常只有几个固定的选项，例如“男”、“女”、“未指定”等。

在这种状况下，能够 应用整数 来示意，约定一个小的整数来示意性别，比方，0：未指定，1：男，2：女。

也能够 应用字符串类型 (VARCHAR) 来存储性别信息。这种形式在表白上更直观，但它比简略数据类型更简单、更消耗资源。

在这个场景下，字符串类型 绝对于 整数类型 来说，其须要占用更多的存储空间，查问排序时也须要消耗更多的 cpu 和内存资源，此时字符串类型将被定义为简单类型，整数类型绝对的就是简略类型了。

在设计数据库时，思考应用简略数据类型而不是简单数据类型能够在确保足够表达能力的同时，进步数据库操作的效率。

思考数据精度

在数据库设计时，抉择适合的数据精度是十分重要的。抉择过高或过低的精度都会带来问题：过高的精度可能会导致不必要的存储空间节约和性能降落，而过低的精度则可能导致数据失真，无奈满足业务需要。

常常的一个常见误区是数据精度越大越好，然而业务场景并不需要那么准确，此时应用过高的精度意味着须要更多的存储空间，这在大型数据库中尤其成问题，可能导致额定的存储老本。更高的精度可能会导致计算速度变慢，尤其是在进行数学运算、排序和索引操作时。

此时应该是从业务需要登程，抉择最为适合的数据精度，既满足了业务要求，也防止了存储空间的节约和查问性能的降落。

思考扩展性

数据库设计时，须要思考到后续需要的变动，随着工夫的推移，数据库设计应该可能很好得适应业务的增长和变动，而不须要进行低廉的重构。

下面提到了数据类型应该越小越好，然而这个须要思考后续的扩展性。比方，当抉择数值类型时，如果预计记录数量会十分大，就应该抉择 BIGINT 而不是 INT。对于字符串类型，此时应该调配一个足够包容将来可能增长的内容长度的大小。

再比方字符串类型的抉择，如果字符串长度在以后是不可预感的，此时应用 VARCHAR 类型 绝对于 CHAR 类型就更为灵便，它能够存储可变长度的字符串，节俭空间并且能够包容将来长度的变动。

总之，当数据库设计时，要充分考虑到后续可能的变动，防止在数据库须要反对更多数据和更简单查问时进行老本昂扬的重构。

## 抉择什么类型呢
回到文章结尾的问题，咱们就有几种不同的数据类型抉择来存储这个 status 字段，如VARCHAR 类型，ENUM 类型，TINYINT 类型，此时咱们应该应用哪个字段类型呢?

这里咱们应用下面几个简略准则来帮忙咱们做出判断，从而帮忙咱们做出更好的抉择。

基于以上剖析，能够看进去，相比于VARCHAR 和 ENUM 类型，TINYINT 是一个适合的抉择，其提供了最好的存储效率，数据处理性能，可扩展性也比拟强，齐全可能适应将来业务需要的变动。

基于此，status 字段类型最终 抉择 TINYINT 字段类型。最终的表构造如下:

CREATE TABLE orders (   
    order_id INT AUTO_INCREMENT PRIMARY KEY, -- 订单 ID，主键，自增
    customer_id INT NOT NULL,                -- 客户 ID，假如已在其余表中定义
    order_date DATETIME NOT NULL,            -- 订单日期和工夫
    total_amount DECIMAL(10, 2) NOT NULL,    -- 订单总金额，保留两位小数
    status TINYINT NOT NULL,                 -- 订单状态，应用 TINYINT 类型
);  

总结

MySQL 反对的数据类型十分多，在适合的场景下，抉择正确的数据类型对于取得高性能至关重要。

本文讲述了几个简略的准则，如抉择最小存储空间的数据类型，应用内建类型，优先应用简略类型等。

这几个准则的核心思想，都是尽量抉择更为简略的数据类型，缩小磁盘空间或者 cpu 资源的节约，从而取得更好的性能。

通过这几个简略的准则，心愿可能帮忙你在数据库设计时做出更好的抉择。

本文由 mdnice 多平台公布