mysql性能优化(一)

本文主要是介绍mysql性能优化(一)，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

1.索引简介

1.1什么是索引

索引是帮助mysql高效获取数据的数据结构。索引的本质是一种排好序的快速查找数据结构

索引的目的是在于提高查询效率，可以类比字典

1.2索引的优劣势

优势：

提高数据的检索效率，降低数据库的io成本

通过索引列对数据排序时，降低数据的排序的成本，降低了CPU的消耗

劣势：

索引的数据结构保存了索引字段与主键的关系，进而指向实体表的记录，会占用一定的空间。

索引虽然大大提高了查询速度，同时却会降低更新表的速度，因为更新表数据时，同时也要更新这条数据对应字段索引的数据结构的指向

1.3索引的分类

单值索引：

即一个索引只包含单个列，一个表可以有多个单列索引（单值索引最好不超过5个）

唯一索引：

索引列的值必须唯一，但允许有空值

复合索引：

即一个索引可以包含多个列

--- 创建索引
create [unique] index indexName on mytable(columname(length))

alter mytable add [unique] index [indexName] on (columname(length))

--- 删除索引
drop index [indexName] on mytable
--- 查看索引
show index from mytable

1.4索引的结构分类

Btree

Hash

full-text

R-Tree

1.5哪些情况需要创建索引

1.主键自动建立唯一索引

2.频繁作为条件查询的字段

3.查询中与其他表关联的外键字段

4.频繁更新的字段不适合创建索引

5.减少单值索引创建，尽量用组合索引代替单值索引

6.经常使用的排序字段可以通过建立索引大大提高排序速度

7.统计或者分组字段

1.6哪些情况不需要建立索引

1.表记录太少（少于百万级别的表，不必要建立索引）

2.经常增删改的表

3.重复数据多的列尽量不要建立索引

2.性能分析

2.1mysql查询优化器

mysql中有专门负责优化select语句的优化器模块，主要功能是：通过计算分析系统中收集到的统计信息，为客户端请求的Query提供它认为最优的执行计划

当客户端向mysql请求一条Query，命令解析器模块完成请求分类，区别出是select并转发给mysql的查询优化器（Query Optimize)时，查询优化器会对整条查询语句进行优化，处理掉一些常量表达式的预算，直接换算成常量表达式。并对查询条件进行简化和转换，去掉一些无用或显而易见的条件、结构调整等。然后分析查询语句中是否有Hint信息，如果有，看显示的Hint信息是否可以完全确定该查询语句的查询 计划。如果没有Hint信息或者Hint信息不足以确定执行计划，则会读取所涉及对象的统计信息，根据查询语句进行写相应的计算分析，得出最后的执行计划

2.2mysql常见瓶颈

CPU：CPU在饱和的时候一般发生在数据装入内存或从磁盘上读取数据的时候

IO：磁盘I/O瓶颈发生在装入数据远大于内存容量的时候

服务器硬件的性能瓶颈：

2.3Explain（查看执行计划）

使用Explain关键字可以模拟优化器执行SQL查询语句，从而知道MySQL是如何处理你的sql语句的，分析你的查询语句或是表结构的性能瓶颈

2.3.1explain之id

select查询的序列号，包括一组数字，表示查询中执行select子句或操作表的顺序

id相同：id相同执行顺序由上至下

explain select t2.* from t1, t2, t3 where t1.id = t2.id and t1.id = t3.id and t1.other_column = ''

id不同：id越大优先级越高

explain select t2.* from t2 where id = 
			(select id from t1 where id = (
							select t3.id from t3 where t3.other_column = ''));

id既有相同又有不同：id相同可认为执行顺序相同，采取由上而下，id不同的id越大，执行优先级越高

explain select t2.* from (select t3.id from t3 where t3.other_column = '') s1, t2 where s1.id = t2.id

derived2表示的是s1表，它是一个衍生t3的一张虚表

关于id的总结：

查询时尽量让小表驱动大表，即小表可以作为子句，放到括号里面，提高小表的执行优先级

2.3.2explain之select_type

查询的类型，主要用于区别普通查询、联合查询、子查询等复杂查询

SIMPLE：

简单的select查询，查询中不包含子查询或者union查询

PRIMARY：

查询中若包含任何的复杂的子部分，最外层查询则被标记为PRIMARY

SUBQUERY：

在select或where列表中包含了子查询

DERIVED：

在FROM列表中包含的子句查询会被标记为DERIVED（衍生），MYSQL会递归执行这些子查询，把结果放在临时表里

UNION:

被UNION的select语句会被标记为UNION

UNION RESULT:

从UNION表获取结果的select，即UNION合并的结果集

2.3.3explain之type

显示查询使用了何种类型，从最好到最差依次是：

system > const > eq_ref > ref >fulltext >ref_or_null > index_merge > unique_subquery > range > index > ALL

工作中常接触到的：一般至少优化到range，最好到ref

system > const > eq_ref > ref > range > index > ALL

system ：

表里只有一行记录（等于系统表），这是const类型的特例，平时不会出现，这个也可以忽略不记

const ：

表示通过索引，一次就找到了，const用于比较primary key或者unique索引。因为只匹配一行数据，所以很快。如将主键至于where列表中，Mysql就能将该查询转换成一个常量

explain select * from (select * from t1 where id =1 ) d

eq_ref:

唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配。常见于主键或唯一索引扫描

explain select * from t1, t2 where t1.id = t2.id ;

ref:

非唯一索引扫描，返回匹配某个单独值的所有行，本质上也是一种索引访问，它返回所有匹配某个单独值的行，所以它应该属于查找和扫描的混合体

explain select * from t1 where col1 = 'ac' ;

range：

只检索指定范围内的行，使用一个索引来选择行。key列显示了使用了哪个索引。一般就是在你where语句中出现了between、>、<、in等查询。这种范围索引扫描比通过索引全表扫描要好，因为它只需要开始于索引的某个点，而结束于另一个点

explain select * from t1 where id between 30 and 60 ;

index:

full index scan与ALL的区别为index类型只遍历索引树，这通常比ALL快，因为索引文件通常比数据文件小。也就是index和ALL都是读全表，但是index是从索引文件中读取而ALL是从磁盘数据文件中读取

explain select id from t1

ALL:

full table scan ,将遍历全表以找到匹配的行

select * from t1 where without_index_col = '' ;

2.3.4explain之possible_keys

显示可能应用到这张表中的索引，一个或多个。查询涉及到的字段上若存在索引，则该索引将被列出，但实际查询不一定使用（mysql分析推测肯能用到的索引，并非实际使用）

2.3.5explain之key

实际使用的索引，如果为NULL则没有使用索引。

若查询中出现了覆盖索引，则该索引仅出现在key列表中。（覆盖索引是指，所查询的列的个数和顺序和实际建立的复合索引的列以及顺序一一对应）

explain select col1, col2 from t1

2.3.6explain之key_len

表示索引的长度。在不损失精确性的情况下，长度越短越好。key_len显示的值为索引字段最大可能值，并非实际使用长度，即key_len是根据表定义计算而得，不是表内检索出得。

2.3.7explain之ref

显示索引的哪一个列被使用了，如果所用列没有索引，显示为NULL

explain select t2.* from t1, t2 where t1.col1 = t2.col1 and t1.col2 = 'ac';

先加载t2表，全表加载 ；

然后加载t1表，通过shared数据库中的t2表的col1字段以及自身表WHERE语句中使用索引字段col2；

2.3.8explain之rows

根据表统计信息及索引选用情况，大致估算出找到所需记录需要读取的行数

建索引之前：

explain select * from t1, t2 where t1.id = t2.id and t2.col1 = 'ac' ;

建立索引之后

create index idx_col1_col2 on t2(col1,col2) ;

explain select * from t1, t2 where t1.id = t2.id and t2.col1 = 'ac' ;

通过在t2表建立索引前后比较，在对t2表建立组合索引后，读取索引所需要的行数rows大大减少

2.3.9explain之Extra

包含不适合在其他列中显示但十分重要的额外信息。

Using filesort

说明mysql会对数据使用一个外部的索引排序，而不是按照表内的索引顺序进行读取。mysql中无法利用索引完成排序的操作称为“文件排序”。出现这种情况尽量优化调

一般建立完组合索引后，order by 和group by 的字段最好和组合索引字段的数量和顺序保持一致

explain select * from t1 where col1 = 'ac' order by col3

Extra中Using filesort说明mysql没有按照表内索引排序

修改语句为

explain select * from t1 where col1 = 'ac' order by col2, col3

发现Extra中的Using filesort没有了，修改后的性能更高

Using temporary

使用临时表保存中间结果，mysql在对查询结果排序时使用临时表，常见于排序order by 和分组查询group by.

出现临时表的创建是及其伤数据库性能的，必须进行优化。

一般建立完组合索引后，order by 和group by 的字段最好和组合索引字段的数量和顺序保持一致

explain select col1 from t1 where col1 in ('ac','ab','aa') group by col2

修改为

explain select col1 from t1 where col1 in ('ac','ab','aa') group by col1, col2

Using index

表示相应的select操作中使用了覆盖索引（covering index,如果要使用覆盖索引，查询的列的个数和顺序和实际建立的复合索引的列以及顺序一一对应)，避免直接访问表的数据行，效率不错；

如果同时出现了使用Using where，表明索引被用来执行索引键值的查找；

如果没有出现Using where，表明索引用来读取数据而非执行查找动作；

explain select col1, col2 from t1

Using where

表明使用了where进行了过滤

Using join buffer

表示使用了连接缓存

这篇关于mysql性能优化(一)的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！