高性能索引策略

1、独列的列是指索引不能是表达式的一部分,也不能是函数的一部分。
始终将索引单独放在比较符号的一侧
 
下面这两种就是有问题的:
select * from user where id +1 =5;
select * from user where (left(modifydate,10)-left(creationdate,10))>30;
 
2、如果需要做索引列的很长,可以使用模拟hash索引的方式,使用CRC32哈希函数索引列进行hash,对hash后的字段进行增加索引。
 
3、如果需要做索引列的很长,可以索引开始的部分字符,这样可以节省空间,提供索引效率。
 
4、计算索引的选择性:表A中一个索引列不重复的数量时T,数据表A所有行为S,那么索引的选择性为T/S,索引的选择性越接近1越好。表明冲突越少。
唯一索引的选择性为1,所以这是最好的索引,性能也是最好的。
 
5、对于字段太长的索引,可以通过截取开始一部分进行加索引,可以通过索引的选择性来做评判标准或者看不同列值出现的次数做比较。
先以不同列出现的次数来说明:
例如:
如果使用完成的列做索引,每个不同列值得出现的词数可能都在50左右
如果截图列的前3个字符做索引,每个不同列值得出现的词数可能都在300左右
如果截图列的前4个字符做索引,每个不同列值得出现的词数可能都在200左右
如果截图列的前5个字符做索引,每个不同列值得出现的词数可能都在50左右
 
那通过上面的方式可以看到截取前5个字符做左右比较好,与不进行截取时相近。
 
在以索引选择性来做评判标准:
例如:
如果使用完成的列做索引,索引的选择性0.61
如果截图列的前3个字符做索引,索引的选择性0.23
如果截图列的前4个字符做索引,索引的选择性0.45
如果截图列的前5个字符做索引,索引的选择性0.57
 
那通过上面的方式可以看到截取前5个字符做左右比较好,与不进行截取时的索引选择性相近。
 
最好是同时使用上面两种方式来评定。
 
前缀索引的缺点:
Mysql无法使用前缀索引做group by和order by
也无法使用前缀索引做覆盖扫描。
 
6、多列索引
常见错误是为每列单独创建索引 或者 按照错误的顺序创建索引
 
mysql可以使用两个单列索引进行扫描,并将结果进行合并。
 
索引合并(index merge)策略可以解决一个查询中使用到多个单列索引的情况。
 
7、选择索引顺序
多列索引即一个索引中包含多了列,
多列索引的顺序至关重要
在一个多列的B-tree索引中,索引列的顺序意味着首先按照最左列进行排序,其次是第二列等等,所以索引可以按照升序或者降序进行扫描,以满足精确符合类顺序的groupby order by 和distinct等子句的查询。
 
基本的策略是选择性最高的列放在最前面。可以通过查询索引中各个列的“索引的选择性”来判断,“索引的选择性”约接近1,应该放在最前面。
 
8、覆盖索引
Mysql可以使用索引来直接获得列的数据,这样就不需要读取数据行。
如果一个索引包含所有需要查询的字段值时,把这种情况称为“覆盖索引”
 
例如:
email和sex组成多列索引
select email,sex from user where email='1' and sex='1';
这种情况下就是覆盖索引
 
9、使用索引扫描来做排序
Mysql可以通过两种方式生成有序的结果:通过排序操作 或者 按照索引顺序扫描。
如果explain 出来的 type列值为Index,则说明Mysql使用了索引扫描做排序。
 
只有当索引的列顺序与order by 子句的顺序一致,并且 所有列的排序方向(正序或者倒叙)都一样事,Mysql才能够使用索引来对结果进行排序。
 
10、冗余和重复索引
应该避免重复索引
 
Mysql允许在一个列中创建多个索引,Mysql需要单独维护重复索引,并且优化器在优化查询的时候也需要逐个进行考虑,因此重复索引会影响性能。
 
举例:
id为主键,id又加了索引,id再次加上了unique唯一限制,实际上mysql的唯一限制和主键限制都是通过索引实现的,因此这个例子中增加了三个重复的索引。
 
冗余索引:(A,B)索引与(A)索引,因为(A,B)索引已经包含了(A)索引,所以(A)索引是冗余索引。
 
索引越多,索引的维护成越高,会导致insert、update、delete性能变差
 
11、未使用的索引
对于未使用的索引应该考虑删除掉
 
12、索引与锁
索引可以让查询索引更少的行
锁定超过需要的行会增加锁竞争并且减少并发性。
Innodb只要在访问行时才会对其加锁,而索引能减少Innodb访问的行数,从而减少锁的数量

猜你喜欢

转载自www.cnblogs.com/use-D/p/9563452.html