数据库表结构设计的优化

在设计数据库结构的时候，要分别对表和字段进行相应的优化设计。当然还有其他的方面，其他的方面的优化知识可以去看看我的博文中Mysql分类的文章。

表方面

• 核心字段且常用字段，应该建立建立成定长，比如说int ,char等定长，并且这些定长的字段放在一张表中，这种表又称为Fixed Format，固定格式。
• 常用字段和不常用字段要分离。需要结合网站具体的业务来分析,分析字段的查询场景,查询频度低的字段,单拆出来。
• 在1对多的情况下，需要在关联统计的表上添加冗余字段。

字段方面

• 字段类型优先级

整型 > date,time > enum,char>varchar > blob,text

• 列的特点分析

（1）整型
定长，没有国家/地区之分，没有字符集的差异。比如 tinyint 1,2,3,4,5 <--> char(1) a,b,c,d,e。从空间上,都是占1个字节,但是 order by 排序, 前者快？
原因: 后者需要考虑字符集与校对集(就是排序规则)

（2）time
定长，运算快，节省空间。 考虑时区，写sql时不方便 where > ‘2005-10-12’;

（3）enum 枚举型
能起到约束值的目的,内部用整型来存储,但与char联查时,内部要经历串与值的转化。性别等字段最好用tinyint，不要用enum型。

（4）字符型
char，定长，需要考虑字符集和(排序)校对集
varchar, 不定长，要考虑字符集的转换与排序时的校对集,速度慢
text/Blob，无法使用内存临时表(排序等操作只能在磁盘上进行)

• 注意点

（1）性别：
以utf8为例，char(1) , 3个字长字节
enum(‘男’,’女’); 内部转成数字来存,多了一个转换过程
tinyint() , // 0 1 2 // 定长1个字节.

（2）够用就行,不要慷慨 (如smallint,varchar(N))
原因: 大的字段浪费内存,影响速度,
以年龄为例 tinyint unsigned not null ,可以存储255岁,足够。用int浪费了3个字节
如果varchar(10) ,varchar(300)存储的内容相同, 但在表联查时,varchar(300)要花更多内存

（3）尽量避免用NULL()
原因: NULL不利于索引,要用特殊的字节来标注.
在磁盘上占据的空间其实更大.(mysql5.7已对null做的改进,但查询仍是不便)