MySQL表设计好与坏直接关系到性能优化之根本，一般表的设计为了维护简单减少存储等因素都会遵循范式化的规则，为了查询效率我们一般都会有一些数据冗余，就会用到反范式化的设计，网上也有很多这方面的介绍，这里就不过多的解读了。
表字段类型直接关系数据的存储及查询效率，下面列举一些注意事情（引擎默认为innodb）：
1、选择合适的字段类型，例如一个status状态字段，一般而言只会存在0、1、2几个不同值，我们可以使用tinyint绝不使用int，int占用空间为tinyint的四倍。又比如性别字段以中文男女分别时可以定义为enum类型，对查询效率有提升
2、字符类型选择合适的长度：
char：定长字符类型，例如一个name字段设计为char(10)，无论存储1个还是10个字符，在磁盘及内存中都会分配10个字符的空间做存储
varchar：可变长字符类型，but只是对磁盘存储而言为可变长度，内存中依然按照设计时所给的字符长度分配空间
假如一个字段不长且能固定长度的使用char比varchar效率更高。
3时间类型字段选择： datetime占用6字节，timestamp占用4字节
4、选择顺序增长并且长度不大的整型字段做主键，MySQL乃索引组织表，数据和主键索引存在于一个数据页上，并且辅助索引都存在主键值，主键长度小有利于减少磁盘存储空间提高扫描速度，B+tree索引都是按顺序存储，设计主键为增长类型可以有效的降低数据页分裂，提高扫描速度。
5、保持每个字段不为null，采用默认值或者空字符代替，null在存储时为标识符，在做扫描时会对null进行计算增加开销。
6、除去text、blob等长字符类型的字段数据一行数据最多只能有65535字节长度的数据
7、一行数据长度加主键索引长度尽量不能超过8K，B-tree索引原则一页最少存储两条数据保持平衡，如果查过8K的长度，就会发生部分数据溢出的情况，降低查询效率。
8、慎用长字符类型字段：
compact:行格式为compact时长字符类型字段聚集索引页只存储前768字节数据，其余部分存于一个溢出页
dynamic:行格式为该选项并且innodb_file_format=Barracuda时，当不合适存储全部数据于聚集索引页时，只存储20字节的指针，指向数据存放的溢出页
不管是varchar的长类型或者是text、blob等的长字符类型，两个字段之间的溢出页不能共享，这样使得一个有多个长字符类型的表，在做字段查询时效率大大降低。