Mysql

关注公众号 jb51net

关闭
首页 > 数据库 > Mysql > MySQL 数据表设计误区

MySQL 常见的数据表设计误区汇总

作者:岛上码农

虽然会有一些常规意义上的数据表错误设计和优秀设计原则,但是同样也会有 MySQL 特定的一些情况,这会导致我们犯一些 MySQL 特定的错误。本篇讨论常见的设计误区。

误区一:过多的数据列

MySQL 存储引擎的 API 是按照行缓冲区方式从服务端和存储引擎复制数据。服务端将缓冲区数据解码成数据列。然而,将行缓冲区的格式转换为数据行数据结构的列可能会代价很高。MyISAM 固定使用与服务端匹配的行格式,因此无需转换。然而,MyISAM 的可变行格式以及 InnoDB 的行格式总是需要进行转换。转换的代价依赖于列的数量。如果当数据表的列超过上百列的时候,会引起很高的 CPU 资源消耗——即便是使用到的列很少。曾经看过一篇文章,指的是一个多语言的解决方案,直接简单粗暴地将系统支持的语言用对应的列表示,例如:

CREATE TABLE t_multi_language_news (
  id INT PRIMARY KEY,
  title_cn VARCHAR(32),
  title_en VARCHAR(32),
  title_it VARCHAR(32),
  ...
  content_cn VARVHAR(256),
  content_en VARCHAR(256),
  conntent_it VARCHAR(256),
);

这种方式随着系统支持的语言越多,数据表的列越多,最终导致性能严重下降。如果你设计一个数据表的列数量超过100时,就需要考虑你的设计是否合理了。 **应对方式:**首先是考虑业务本身的设计是否合理,如果确实一个实体需要很多字段来描述,那么可以拆分数据表,通过扩展信息表来做。举个例子,对于资讯类的数据表,因为内容一般占据的空间会比较大,但是在列表不会直接查看,就可以拆成资讯主表和资讯详情表,主表存储标题、时间、摘要、缩略图附件 id 等列表要查看的信息即可。而资讯详情可以存储资讯的内容、来源、原文链接等信息。

误区二:过多的联合查询

MySQL 一次联合查询最多只能61张表。而有些设计主张不做冗余字段设计,这会导致复杂业务时需要连接多张表查询。即便是联合的表数量低于61个,也会引起性能的下降,而且整个 SQL 语句的维护将变得十分困难。作为一个设计的首要原则,就是如果想追求速度的话,一次查询不要跨太多的数据表做联合查询,尤其面临高并发场景的时候。 **应对方式:**首先,对于确定不会改变的字段,可以考虑冗余字段的方式减少联合查询。例如,一家企业的所属省份信息,就可以把省份代码、省份名称冗余了,而无需再通过省份代码去查询省份名称。其次,确实需要查其他表的情况下,可以考虑使用分步查询的方法,通过应用程序完成数据的组装,这种效率在数据表很多的时候会更高效,而且代码也更好维护。 误区三:万能的枚举 例如下面这种表设计:

CREATE TABLE t_countries (
  ...
  country ENUM('', '1', '2', ..., '45'),
  ...
);

这种方式本来可以通过一个以整数为 key的字典的查找表实现。如果是业务上增加了一个枚举,意味着整个表都需要使用 ALTER TABLE更新。而如果是使用应用代码的查找表,只需要增加新的键值对就好了。 **应对方式:**如果枚举确定不会变动(例如性别),那么没问题。如果枚举可能会增加,那么尽可能地通过应用程序来实现。

误区三:滥用 SET替代 ENUM

枚举ENUM 类型是数据表列的值只能是值集合中的一个,而 SET 类型是该列可以有一个或多个值。如果确定一个列只会有一个值,那么就应该优先使用枚举,而不是集合。例如下面的例子就是典型的滥用:

CREATE TABLE t_payment_way (
  ...
  is_default SET('Y', 'N') NOT NULL DEFAULT 'N',
  ...
);

很显然,is_default 要么是 Y,要么是 N,因此这里应该使用 ENUM。 **应对方式:**从业务层面考虑列的值是不是可能有多个,如果只有1个可选值那么就用 枚举ENUM。

误区四:生硬地避免NULL

很多文章都讨论过尽可能地避免使用 NULL,对于大部分场景这是一个好的设计,我们可以通过0,空字符串,约定的值等来表示空值。然而,不要因为这个而生硬套用,如果是这个值本身就是一个无意义的值的时候,那么使用 NULL 可能更合适。例如,如果要是有-1代表一个无意义的整数,可能会导致代码很复杂,甚至可能引起 bug。例如下面的例子:

CREATE TABLE t_person (
  birthday DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
  ...,
);

将一个 DATETIME 类型的默认值设置为全部是0会很奇怪,假设我们要统计人员的年龄平均值的时候,会引起莫名其妙的问题,而这种场景使用 NULL 就不会纳入到统计中来。可以通过设置 MySQL 的 SQL_MODE 参数禁止使用无意义的日期,避免出现这种情况。 **应对方式:**设计表的时候可以尽量使用 NOT NULL 避免空值,但是不要过于生硬,对于有些字段使用默认值无法表名意义或与实际不符时,也是可以选择使用 NULL 列的。只是,需要注意索引列不要使用NULL。而实际上,绝大部分索引列不太可能会是 NULL。

误区五:使用整数替换时间戳

之前有讲到过时间格式如何选择的问题,实际上有些开发者会使用整数来存储时间戳,他们的理由是这样效率更高。从某种意义上来说,可能会提高一点效率,但是帮助不大,因为在 MySQL 内部DATETIME 和 TIMESTAMP 本身就是用整数存储的。而如果使用整数存储时间的话,意味着应用程序中需要做时间转换,或者是 SQL 语句要对指定的字段进行时间转换,带来的收益可能得不偿失。 **应对方式:**尽可能地使用 DATETIME 存储时间,如果需要存储秒级精度一下的时间,那么可以考虑使用 BIGINT 来存储。

误区六:忘记字段的最大存储范围

在实际中设计表的时候会忘记数据类型的存储范围,比如使用 TINYINT(2)并不是只能存储两位整数,实际TINYINT(2) 可以存储的范围是-128-127。 存储超过255的整数。这种错误在使用整数类型的时候很容易出现问题,在插入整数的时候,MySQL 不会检查实际的整数位数,而是按对应存储字节数的范围存入,这种情况假设不注意会存入无意义的值。例如下面的 INSERT 操作会成功,而我们可能误以为 TINYINT(2)只能存储2位整数:

CREATE TABLE t_int_test (
    id INT PRIMARY KEY,
    number TINYINT(2)
);

INSERT INTO t_int_test (id, number) VALUES (3,123);

应对方式:在应用程序中做数据校验。

结语:

在实际设计数据表的过程中,除了需要考虑每个字段的数据类型之外,还需要考虑存储空间大小。对于常用的一些字段,如时间、标题、备注等,最好是内部形成一定的规范,大家遵照规范执行,并且增加校验能够避免很多问题。

以上就是MySQL 常见的数据表设计误区汇总的详细内容,更多关于MySQL 数据表设计误区的资料请关注脚本之家其它相关文章!

您可能感兴趣的文章:
阅读全文