Mysql范式与数据类型选择

良好的逻辑设计与物理设计是高性能的基石，当我们在设计数据表结构的时候，应该跟根据业务逻辑来分析具体情况，然后设计出比较合理，高效的数据表结构

在数据表结构设计中，不得不提的就是 范式 与 数据类型 了

Mysql三范式

• 字段不可分；即字段具有原子性 字段不可再分,否则就不是关系数据库;
• 有主键，非主键字段依赖主键; 唯一性 一个表只说明一个事物
• 非主键字段不能相互依赖；每列都与主键有直接关系，不存在传递依赖

范式的优点与缺点

• 优点

  • 范式化设计更新通常比反范式化更新要快
  • 当数据高度范式化时，就只有少量或者没有重复数据，这样修改的时候就只需要修改少量的数据
  • 范式化的表通常比较小，可以更好的放在内存里面，操作就会更容易
  • 因为范式化设计之后，冗余数据较少，所以在执行某些查询的时候可能就不会用到 group by ， distinct 这样也提高了查询效率
• 缺点
  因为严格遵循范式化设计的话。在某些业务场景下可能会查询多个表。这样的同样会使得查询效率变的很低。而且在某些时候因为多表查询的原因，可能某些索引不会被命中。

这里我们看到范式化的设计有优点也有缺点，所以在实际的项目中，我们通常是混范式化设计。

某些表完全遵循范式化；某些表遵循部分范式化设计。在设计某些表的时候 会用到反范式化的思想，将某些数据存到同一张表中。这样可以减少很多关联查询，也可以更好的去设计索引关系。

比如 users 表 与 user_messages 表中，都会保存一个 user_account_type 字段。这样的话，在单独查询 user_account_type=1 的消息总数时就不需要再去关联 users 表了。

数据类型

Mysql支持的数据类型有很多种，所以选择正确的数据类型对提高性能有着至关重要的作用。但是不管哪种数据类型我们都应该参考下面几个原则

• 更小的通常更好 ；更小的数据类型通常更快，因为他们占用更少的磁盘、内存、CPU缓存。
• 简单就好 ；操作简单的数据类型通常需要更少的CPU周期。例如：整型比字符串操作代价更低
• 尽量避免NULL ；如果查询中包含可为 Null 的列，对于 Mysql 来说更难优化，因为可以为 null 的列使得索引，索引统计和值都变的更加复杂

整数类型

Mysql 的整数类型有 TINYINT , SMALLINT , MEDIUMINT , INT , BIGINT 。他们使用到的储存空间分别是, 8 , 16 , 24 , 32 , 64 位。值的范围是-2 ^(N-1) 到2 ^(N-1) -1

整形可以选择 UNSIGNED 属性，表示是否有符号，不允许为负值。

如 TINYINT UNSIGNED 值的范围 0~255， 而 TINYINT 值的范围是-128-127。需要注意点是有符号跟无符号使用相同的储存空间，拥有相同的性能，所以可以根据实际情况来选择类型。

字符串类型

VARCHAR , CHAR 是两种最主要的字符串类型，

• VARCHAR 类型用于储存可变字符串，是常见的字符串类型。它比定长类型更节省空间。
• CHAR 定长字符串类型，分配固定长度的空间。在保存某些定长字符串时比 VARCHAR 更有优势、比如 md5 定长字符串，因为定长类型字符串不容易产生碎片。

对于 VARCHAR(5) 和 VARCHAR(100) 储存 hello 的空间开销是一样的，那么是不是我们就可以定义长度为 100 呢?当然不是了，更长的列会消耗更多的内存，因为 Mysql 通常会分配固定大小的内存块来保存内部值。所以最好的策略就是分配合理的长度，这样就分配到真正需要的 空间。

日期，时间类型

• DATETIME 类型，能够保存1001-9999年，精度为秒，与时区无关。
• TIMESTAMP 类型，保存了从1970-01-01午夜到现在的秒数，只使用了4个字节，只能表示1970-2038年。 TIMESTAMP 依赖于时区。 TIMESTAMP 在默认情况下，如果没有指定列的值，会把列的值设置为当前时间，在更新的时候也可以更新列的值为当前时间。

通常情况下应该尽量使用 TIMESTAMP ,因为它比 DATETIME 空间效率更高，有时候我们会将Unix时间戳保存为整数值以表示当前时间，实际上并不会带来任何收益。

上面列举了几个常用的 mysql 类型，在实际使用中可以根据业务选择最优的方案。一般情况下遵循 更小的通常更好 , 简单就好 , 尽量避免NULL 是没有问题的。

关于mysql的数据类型选择，就写到这里。后面也会写一些关于索引优化方面的文章，如果问题欢迎大家指出。