mysql优化方式

Query语句优化的基本思路和原则

在Mysql中有一个专门负责优化select语句的优化器模块，其主要功能是通过计算分析系统中收集的各种统计信息，为客户端请求的Query给出最优的执行计划。

（1）优化更需要优化的Query

高并发低消耗的Query对整个系统的影响高于低并发高消耗的大。所以先优化高并发低消耗的Query

（2）永远用小结果集驱动大的结果集

MySQL中join（连接查询或者子查询）都是通过嵌套循环来实现的。驱动结果集越大，所需要的循环越多。驱动结果集是外层循环。

（3）尽可能在索引中完成排序

（4）仅用最有效的过滤条件（查找书中内容）

充分利用Explain和Profiling

Explain展示执行计划，profiling展示cpu  内存利用率

合理设计并利用索引

Innodb是B-Tree索引

MyISAM有B-Tree索引和Full-Text索引

单建索引还是组合索引

经常会有多个字段一起作为查询过滤条件存在于WHERE子句中。这时必须判断是在过滤性最好的字段上建立索引，还是在过滤条件单所有字段上建立一个组合索引。

组合索引因为有多个字段存在，理论上被更新的可能性肯定比单间索引大很多，带来的附加成本会高。但是当WHERE字句中查询条件含有多个字段时，通过多个字段组成组合索引的查询效率肯定比单建索引高很多。

多个单建索引的情况也不好。Mysql优化器大多数情况下只会选择其中一个索引，放弃其他索引。

一般应用中，只要不是其中某个过滤字段在大多数场景下能过滤90%以上的数据，而且其他过滤字段会被频繁更新，一般选择组合索引

Query的索引选择

创建索引： CREATE index group_message_author_subject on group_message(author,subject(16))        //组合索引

显示某个表的索引：show indexes FROM group_message\G

有时候Mysql系统统计信息不够完整，会造成他并没有选择一个真正最优的索引，而是选择了其他查询效率较低的索引，所以我们必须认为的强制选择使用索引。     EXPLAIN SELECT * FROM GROUP_message  FORCE INDEX(idx _group_message_author_subject)WHERE user_id=3 AND author ='3'  AND subject like 'weiurazs%'\G

查看sql执行时间

mysqlslap --create-schma=example --query "SELECT * FROM GROUP_message WHERE user_id=3 AND subject like 'weiurazs%' --iterations =10000

结果会显示出平均时间，最短时间，最长时间

总结：

尽量选择过滤性更好的索引

不要完全相信Mysql的Queqy Optimizer ，可以自己选择索引

如果可以不认为强制，就不要人为干预，否则不利于维护。

索引的弊端

Mysql在更新表的Column ca的数据的同时，必须跟新Column a 的索引数据，最明显的资源消耗就是增加了更新所带来的IO量和调整索引所致的计算量。索引的存储也要占用空间，太多的索引会使存储空间资源消耗增加。

索引的限制

Join的实现原理和优化

1.永远用小结果集驱动大结果集

2.优先优化内层循环，即保证join语句中被驱动表的join字段已经被索引。

Order By优化

尽量使用索引字段，甚至可以增加索引字段

Group By 优化

GROUP BY的实现有三种方式

1.松散索引扫描实现GROUP BY：

完全利用索引扫描来实现，并不需要扫描所有满足条件单索引建即完成操作。

需要满足三个条件：

1.groupby条件字段必须处在统一索引中的最前面的连续位置

2.使用group by时只能使用MAX 和MIN这连个聚合函数

3.如果引用到该索引中GROUUP BY条件之外的字段条件，它就必须以常亮存在；

2.紧凑索引扫描实现GROUP BY 

当GROUP BY 条件字段并不是索引最前面的索引部分或者不是连续的，不能松散型索引扫描。但是如果Query语句中存在一个常量值来引用缺失的索引键，可以使用紧凑型索引扫描。

3.使用临时表实现GROUP BY

当GROUP BY 条件字段并不是索引最前面的索引部分或者不是连续的，不能松散型索引扫描。如果Query语句中不存在一个常量值来引用缺失的索引键，而是索引建是一个范围。那就只能用临时表实现GROUP BY 

distinct优化

同GROUP BY