良好的逻辑设计与物理设计是高性能的基石，当我们在设计数据表结构的时候，应该跟根据业务逻辑来分析具体情况，然后设计出比较合理，高效的数据表结构
在数据表结构设计中，不得不提的就是范式与数据类型了
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的数据类型选择，就写到这里。后面也会写一些关于索引优化方面的文章，如果问题欢迎大家指出。
