首页 > 代码库 > Mysql性能优化笔记

Mysql性能优化笔记

一,索引

1.Innodb索引使用的是B+树

2.尽量简化where条件,比如不要出现 where id + 3 = 5,这无法使用索引

3.索引很大时,可以冗余一列来模拟哈希索引

4.小的表不需要使用索引,很大的表需要用分块技术,也不用索引

5.索引的选择性=不重复的数量/总的数量

选择性越高,效率越高,unique索引选择性为1,效率最好

对于blob,text,很长的varchar类型的列,必须使用前缀索引。

诀窍在于,要选择足够长的前缀以保证较高的选择性,同时又不能太长

创建前缀索引:(city列里长度为7的前缀索引)

alter table sakila.city_demo ADD KEY(city(7))

前缀索引的缺点,无法做ORDER BY和GROUP BY

后缀索引:mysql不支持反向索引,但可以把字符串反转后存储,并基于此建立索引,可以通过触发器来维护索引

 

6、多列索引

对多个列做相交操作(and)时,需要的时一个多列索引而不是多个单独的单列索引

如果在explain中看到有索引合并,应该好好检查一下查询和表单结构,

可以通过参数optimizer_switch来关闭索引合并

 

7.覆盖索引

如果一个索引包含所有需要查询的字段的值,我们就称之为覆盖索引

由于myISAM在内存中只存索引,所以用覆盖索引有严重的性能问题

由于InnoDB的聚簇索引,覆盖索引对InnoDB特别有用

另外,只能用B-tree索引做全文索引

当使用覆盖索引时,EXPLAIN 中的Extra中显示Using index

 

 

查询优化

一般的优化方法有两个

1.确认应用程序是否在检索大量超过需要的数据,这通常意味着访问了太多的行

但有时候也可能是访问了太多的列

2.确认MySQL服务器层是否在分析大量超过需要的数据行

解决方法,加limit,

如果数据库资源紧张,可以考虑用mybatis代替hibernate

取出全部列,会让优化器无法完成覆盖索引扫描这类优化,比如hibernate

不过获取所有列的查询缓存,比多个独立的只获取部分列的查询缓存更有好处

每次看到select * 请去怀疑一下是否真的需要全部取出 

重复查询相同的数据:请把这个数据缓存起来,比如放到session中

 

最简单的衡量查询开销的三个指标:

响应时间,

扫描的行数

返回的行数

这三个指标都会记录到mysql的慢日志中,所以检查慢日志

如果发现查询需要扫描大量的数据行,但返回少量的行,那么可以尝试下面的技巧去优化它

1,使用索引覆盖扫描,把所有需要用的列都放到索引中

2.改变表结构,例如使用单独的汇总表

3.重写这个查询,各种优化

 

有时可以考虑将一个复杂查询分为多个小查询,如果能减少工作量的话

比如删除旧的数据,每次删一点,可以避免一次锁住很多数据

 

分解关联查询的好处

1、缓存效率更高

2、用返回的数据的id来进行顺序查询比用join进行随机关联效率更高

坏处:一条语句分多条,增加连接开销

技术分享

 

 排序优化

无论如何,排序都是一个成本很高的操作,所以从性能角度考虑,尽可能避免排序,或避免对大量数据进行排序

 

Mysql性能优化笔记