一、表的优化:
1: 定长与变长分离
如 time、手机号等，每一单元值占的字节是固定的.
核心且常用字段,宜建成定长,放在一张表，查询速度会很快
而varchar, text,blob,这种变长字段,适合单放一张表, 用主键与核心表关联起来.
2:常用字段和不常用字段要分离
需要结合网站具体的业务来分析,分析字段的查询场景,查询频度低的字段,单拆出来.
3、在1对多,需要关联统计的字段上,添加冗余字段.（”空间换时间”）
好比今日注册用户数或者今日发帖量这种，如果需要连表查，再计算会很耗资源，可以在主表加一个字段，每发一个帖加1，直接查出来就行了
二、列选择原则:
1:字段类型优先级 整型 > 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-10-12’;
enum: 能起来约束值的目的, 内部用整型来存储,但与char联查时,内部要经历串与值的转化
Char 定长, 考虑字符集和(排序)校对集
varchar, 不定长 要考虑字符集的转换与排序时的校对集,速度慢.
text/Blob 无法使用内存临时表(排序等操作只能在磁盘上进行)
关于date/time的选择,大师的明确意见,直接选 int unsgined not null ,存储时间戳
Enum列的说明
a: enum列在内部是用整型来储存的
b: enum列与enum列相关联速度最快
c: enum列比(var)char 的弱势---在碰到与char关联时,要转化. 要花时间.
d: 优势在于,当char非常长时,enum依然是整型固定长度.
当查询的数据量越大时,enum的优势越明显.
5: enum与char/varchar关联 ,因为要转化,速度要比enum->enum,char->char要慢,
但有时也这样用-----就是在数据量特别大时,可以节省IO.
2: 够用就行,不要慷慨 (如smallint,varchar(N))
原因: 大的字段浪费内存,影响速度,
以年龄为例 tinyint unsigned not null ,可以存储255岁,足够. 用int浪费了3个字节
以varchar(10) ,varchar(300)存储的内容相同, 但在表联查时,varchar(300)要花更多内存
3、尽可能的使用 NOT NULL
三、 为搜索字段建索引
没有索引，查询数据都是从表的第一行开始扫描数据，如果给常用的搜索字段建了索引，查询某条数据即使在几十亿条的数据中也能在32次之内找到。
多列一起查的话建复合索引，而不是单独为查询的列建索引。
四、为查询缓存优化你的查询
第一次查询数据库，然后将数据放到缓存中，之后在缓存中读取数据，内存的读写数据比是硬盘20倍以上
五、避免 SELECT *
需要什么就取什么