一、表的优化
定长与变长分离，核心且常用字段，宜建成定长，放在一张表，而varchar，text，blob这种变长字段适合放在一张表，用主键关联
常用字段和不常用字段要分离
需要关联统计的字段上，添加冗余字段（反范式）有时候不遵循规则，反倒利于优化。
二、列的类型选择
列的类型选择原则：
字段优先级 整型 > date，time > enum，char > varchar > blob，text
整型：定长，没有国家/地区之分，没有字符集的差异
比如 tinyint 1,2,3,4,5 <----> char(1) a,b,c,d,e 从空间上都是1个字节， 但是order by 排序，前这快
原因后者需要考虑字符集的校对集（就是排序规则）
time： 定长 ，运算快，节省空间，考虑时区，写sql 时不方便 如where>'2005-12-22'
enum ：能起到约束值得目的，内部使用整型来存储，但与char联查时，内部要经历串与值得转化
varchar： 不定长要考虑字符集的转化与排序时的校对集，速度慢
text/blob 无法使用内存临时表 （排序等操作只能在磁盘上进行）
附：关于date/time 的选择，大佬们的意思是直接选 int unsigned not null 存储时间戳
性别：
char(1),3个字长字节
enum（'男'，'女'）；内部转成数字来存，多一个转化过程
tinyint(1)，//0,1,2 定长1个字节
列的长度选择，原则上够用就行，不要慷慨
原因：大的字节浪费内存，影响速度，
以年龄为例 tinyint unsigned not null ，可以存储255岁，足够，用int浪费3个字节
以varchar(10),varchar(300)存储的内容相同，但是在表联查时，varchar(300)要花更多内存
尽量避免使用null
原因：null不利于索引，要用特殊的字节来标注，在磁盘上占据的空间其实更大， mysql 5.5已经对null做了优化改进，但是查询还是不便
enum 列的说明
enum列在内部是用整型来存储的
enum列与enum列相关联速度最快
enum列比(var)char的弱势---在碰到char关联时要转化，要花时间
优势在于，当char非常长时，enum依然是整型固定长度，查询的数据量越大时，enum的优势越明显
enum与char/varchar 关联因此需要转化，速度比enum和enum，char和char要慢，但是有时也这样用---就是在数据量特别大的时候可以节省IO