mysql 优化（2）索引优化策略

1:索引类型

索引： 作用快速查询；

节点第1层 ， 2的0次方

节点第1层 ， 2的1次方

节点第3层 ， 2的2次方

节点第4层 ， 2的3次方

节点第5层 ， 2的4次方

.。。。

。。。

。。。

节点第31层 ， 2的32次方

加起来 42亿

也就是说 42 亿个数字 最多查 32 次就可以了

普通查询要查21亿次



这就是-----》 B-tree索引

注: 名叫btree索引,大的方面看,都用的平衡树,但具体的实现上,各引擎稍有不同,

比如,严格的说,NDB引擎,使用的是T-tree

Myisam,innodb中,默认用B-tree索引



但抽象一下---B-tree系统,可理解为”排好序的快速查找结构”.



1.2 hash索引 弹簧哈哈哈哈。。。尼玛尼玛。。。

在memory表里,默认是hash索引,
hash的理论查询时间复杂度为O(1)



疑问: 既然hash的查找如此高效,为什么不都用hash索引?

答:

1:hash函数计算后的结果,是随机的,如果是在磁盘上放置数据,
用 算法。。。。。

比主键为id为例,那么随着id的增长,
id对应的行,在磁盘上随机放置.散落的无规律！！

散列算法 分配磁盘空间毫无规律可言！！！

2: 无法对范围查询进行优化. 3:无法利用前缀索引.

比如 在btree中, field列的值“hellopworld”,并加索引

查询 xx=helloword,自然可以利用索引, xx=hello,也可以利用索引.
(左前缀索引)

因为hash(‘helloword’),和hash(‘hello’),两者的关系仍为随机

4: 排序也无法优化.

5: 必须回行.就是说 通过索引拿到数据位置,必须回到表中取数据

------》回行查找 就说只是个字典的目录 必须再去实际翻页



2: btree索引的常见误区

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

例: where cat_id=3 and price>100 ; //查询第3个栏目,100元以上的商品

误: cat_id上,和, price上都加上索引.

错: 只能用上cat_id或Price索引,因为是独立的索引,同时只能用上1个.

alter table add index(cat_id)

alter table add index(price)

alter table add index(goods_id) ---------------------------同时只能用一个 所以。。。。 联合索引 把多个列看成整体的值

index（cat_id ,goods_name, price） --------------------------- 把多个列看成整体的值



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

误: 多列索引上,索引发挥作用,需要满足左前缀要求.
///做前缀要求

以 index(a,b,c) 为例,(注意和顺序有关)

语句

索引是否发挥作用

Where a=3

是,只使用了a列

Where a=3 and b=5

是,使用了a,b列

Where a=3 and b=5 and c=4

是,使用了abc

Where b=3 / where c=4

否

Where a=3 and c=4

a列能发挥索引,c不能

Where a=3 and b>10 and c=7

A能利用,b能利用, C不能利用

同上,where a=3 and b like ‘xxxx%’ and c=7

A能用,B能用,C不能用

为便于理解, 假设ABC各10米长的木板,河面宽30米.

精确匹配,则木板长10米,

Like,左前缀及范围查询,则木板长5米,



自己拼接一下,能否过河对岸,就知道索引能否利用上.

如上例中, where a=3 and b>10, and c=7,

A板长10米,A列索引发挥作用

A板正常接B板, B板索引发挥作用

B板短了,接不到C板,
C列的索引不发挥作用.

以上就是mysql 优化（2）索引优化策略的内容，更多相关内容请关注PHP中文网（m.sbmmt.com）！