Mysql优化的方法

一、表的优化:

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 *

需要什么就取什么