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不支持反向索引，但能够把字符串反转后存储，并基于此创建索引，能够经过触发器来维护索引

 

六、多列索引

对多个列作相交操做（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.重写这个查询，各类优化

 

有时能够考虑将一个复杂查询分为多个小查询，若是能减小工做量的话

好比删除旧的数据，每次删一点，能够避免一次锁住不少数据

 

分解关联查询的好处

一、缓存效率更高

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

坏处：一条语句分多条，增长链接开销

 

 排序优化

不管如何，排序都是一个成本很高的操做，因此从性能角度考虑，尽量避免排序，或避免对大量数据进行排序