Mysql数据库优化(二)

数据库优化:

(计算机优化时间换空间,或者空间换时间)

表的优化:
1.定长与变长相分离
2.常用字段和不常用字段要分离
3.在1对多,需要关联的统计字段上添加冗余字段

列类型选择:

1.字段类型优先级选择整形>date.time >emun ,char >varchar>blob,text
整形:定长,没有国家地区之分,没有字符集差异(字符集校队问题)
emun 原理是内部转化为整形,多了个转化过程,起到约束作用
varchar 不定长 ,需要校队字符集

2.够用就行,
原因:大的字段浪费内存,影响速度 ,比如年龄 tinyint unsigned not null 可以存储255
3.尽量避免null 不利于索引,要用到特殊的字节来标注,在磁盘上占用空间比较大(mysql5.5之前) (is null , is not null)

索引优化:

( mysql用到 btree索引, hash索引 )

索引不仅可以提高查询速度还可以提高排序速度
btree索引:(可以理解为排好序的快速查询结构)
hash索引:在memory表中默认是hash索引(memory表指内存引擎,数据放到内存中的,突然关机会导致数据丢失)

hash索引查询比较高效,为什么都不用hash索引?
1.hash函数计算后的结果是随机的如果是在磁盘上放置数据,以主键id为例,随着id的增长,id对应的行在磁盘上都是随机放置
2.无法对范围查询做优化
3.无法利用前缀索引
4.排序无法优化
5必须回行, 通过索引拿到数据位置后必须回到表中取数据

btree索引的常见误区

1.where条件上都加上索引
where cat_id =3 and price>100 只能用上cat_id
2.多列建立索引后需要,索引都发挥作用
例如创建索引的时候是 index c1234(c1,c2,c3,c4)
尽量c1,c2,c3,c4 不然后面的索引是用不上 ,例如使用like 时后面的索引用不上

聚簇索引与非聚簇索引

聚簇索引与非聚簇索引都是使用的btree索引
索引文件与数据文件是相互独立分开的是非聚簇索引 (Mysiam)
Mysaim ->索引指向行所在的位置
聚簇索引索引与数据文件在一块不用回行查询(数据和索引在一块)innodb
innodb ->主键所用即存贮次键索引指向主键索引

查看使用索引的数量时候可以使用 explain sql 语句 (分析sql 语句,查看sql执行情况)
key_len 代表查询用到的长度