分享Mysql优化思路(2)-木庄网络博客

当前第2页返回上一页

mysql> explain select count(*) from goods \G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: goods
   partitions: NULL
         type: index   
possible_keys: NULL
          key: gid
      key_len: 5
          ref: NULL
         rows: 3
     filtered: 100.00
        Extra: Using index

c：相关优化手法

表的优化与列类型选择

列选择原则：

1：字段类型优先级整型 > date,time > char,varchar > blob

原因：整型,time运算快，节省空间

char/varchar要考虑字符集的转换与排序时的校对集，速度慢

blob无法使用内存临时表

2：够用就行，不要慷慨(如 smallint,varchar(N))

原因：大的字段浪费内存，影响速度

以varchar(10), varchar(300)存储的内容相同，但在表联查时，varchar(300)要花更多内存

3：尽量避免使用NULL

原因：NULL不利于索引，要用特殊的字节来标注.

在磁盘上占据的空间其实更大

索引优化策略

1.索引类型

1.1 B-tree索引(排好序的快速查找结构)

注：Myisam,innodb中，默认用的是B-tree索引

1.2 hash索引

在memory表里，默认是hash索引，hash的理论查询时间复查度为O（1）

疑问：既然hash索引如此高效，为何不都用他？

a.hash函数计算后的结果是随机的，如果是在磁盘上放置数据，以主键为id为例，那么随着id的增长，id对应的行，在磁盘上随机放置。

b.无法对范围查询进行优化

c.无法利用前缀索引，比如在b-tree中，field列的值为“helloworld”，索引查询xx=hello/xx=helloworld都可以利用索引（左前缀索引），但hash索引无法做到，因为hash(hello)与hash(helloworld)并无关联关系。

d.排序也无法优化

e.必须回行，通过索引拿到数据位置，必须回到表中取数据.

2.b-tree索引的常见误区

2.1 在where条件常用的列上都加上索引

例：where cat_id=3 and price>100； //查询第3个栏目，100元以上的商品

误：cat_id和price上都加上索引。其实只能用上一个索引，他们都是独立索引.

2.2 在多列上建立索引后，查询哪个列，索引都将发挥作用

正解：多列索引上，索引发挥作用，需要满足左前缀要求（层层索引）

以index(a,b,c)为例：

语句 索引是否发挥作用
where a=3 是
where a=3 and b=5 是
where a=3 and b=5 and c=4 是
where b=3 or where c=4 否
where a=3 and c=4 a列能发挥索引作用，c列不能
where a=3 and b>10 and c=7 a,b能发挥索引作用，c列不能