MySQL优化分析

MySQL

##1.索引 ###1.概念:索引(Index)是帮助MySQL高效获取数据的**数据结构**。因而可以得到索引的*本质:索引是数据结构。* 简而言之就是“排好序的快速查找数据结构”。因而,索引决定两部分内容,*排序*和*查找*。

在数据之外,数据库系统还维护着满足特定查找算法的数据结构,这些数据结构以某种方式引用(指向)数据,这样就可以在这些数据结构上实现高级查找算法。这种数据结构,就是索引。

2.索引的优劣势:

优势:①类似大学图书馆建书目索引,提高数据检索的效率,降低数据库的IO成本;②通过索引列对数据进行排序,降低数据排序的成本,降低了CPU的消耗

劣势:①虽然索引大大提高了查询速度,同时却会降低更新表的速度,如对表进行INSERT、UPDATE和DELETE。因为更新表时,MySQL不仅要保存数据,还要保存一下索引文件每次更新添加了索引列的字段,都会调整因为更新所带来的键值变化后的索引信息;②实际上索引也是一张表,该表保存了主键与索引字段,并指向实体表的记录,所以索引列也是要占用空间的

3.索引的分类

单值索引:即一个索引只包含单个列,一个表可以有多个单列索引
唯一索引:索引列的值必须唯一,但允许有空值
主键索引:设定为主键后数据库会自动建立索引,innodb为聚簇索引
复合索引:即一个索引包含多个列

4.数据库慢的原理分析

数据库慢主要体现在两方面:检索慢、排序慢

检索慢:大规模io,可以用linux命令iostat -d 2 3来查看。
排序慢:排序慢导致CPU消耗,可以使用linux命令iostat -c 2 3来查看。

故而,数据库慢,要么是IO慢,要么是CPU慢。(导致数据库慢的硬件层次上就这两个因素)

建立索引一定要注意:一张表的索引最多最多建立5个。

单值索引:
create index idx_user_name on user(name);
create index idx_user_weixin on user(weixin);
唯一索引:
索引列的值必须唯一,但允许有空值。
create unique index unique_idx_user_weixin on user(weixin);
复合索引:
create index idx_user_name_age on user(name,age);

5.Explain

Explain是用来查看sql语句的执行计划的。即机器如何来解析执行我们输入的SQL语句。具体用法就是:explain sql语句

explain sql语句之后会出现一个表,该表共有10个字段,分别为:
id,select_type,table,type,possible_keys,key,key_len,ref,rows,Extra。

id

概念:select查询的序列号,包含一组数字,表示查询中的先后顺序。
id相同:执行顺序由上至下。
id不同:按照id的大小顺序执行,即先执行id大的。如果是子查询,id的序号越大优先级越高,越先被执行。
id相同又不同:数字大的先执行,数字相同的按从上到下顺序执行。

select_type

概念:查询类型,主要用于区别普通查询、联合查询、子查询等复杂的查询。共有以下6种不同的查询类型:

(1) SIMPLE:简单的select查询,查询中不包含子查询或UNION
(2) PRIMARY:查询中若包含任何复杂的子部分,最外层查询则被标记为PRIMARY。(一般发生在子查询里面)
(3) SUBQUERY:在select或where列表中包含了子查询。
(4) DERIVED:在from列表中包含的子查询被标记为DERIVED(衍生),MySQL会递归执行这些子查询,把结果放在临时表里。(sql语句查询的原则:小表驱动大表
(5) UNION:如果第二个select出现在union之后,则被标记为UNION;若UNION包含在FROM子句的子查询中,外层的select将被标记为DERIVED。
(6) UNION RESULT:从UNION表中获取结果的select。

table

显示这一行数据是关于哪张表的。

type

概念:访问类型排列。显示查询使用了何种类型。从最好到最差依次是:
system>const>eq_ref>ref>range>index>ALL。
一般来说,得保证查询至少达到range级别,最好能达到ref。

(1)system:表只有一行记录(等于系统表),这是const类型的特列,平时不会出现,这个也可以忽略不计
(2)const:表示通过索引一次就找到了,const用于比较primary key或者unique索引。因为只匹配一行数据,所以很快

如将主键置于where列表中,MySQL就能将该查询转换为一个常量

(3)eq_ref:唯一性索引扫描,对于每个索引键,表中只有一条记录与之匹配。常见于主键或唯一索引扫描
(4)ref:非唯一性索引扫描,返回匹配某个单独值的所有行.

本质上也是一种索引访问,它返回所有匹配某个单独值的行,然而,
它可能会找到多个符合条件的行,所以他应该属于查找和扫描的混合体

(5)range:只检索给定范围的行,使用一个索引来选择行。key 列显示使用了哪个索引一般就是在你的where语句中出现了between、<、>、in等的查询这种范围扫描索引扫描比全表扫描要好,因为它只需要开始于索引的某一点,而结束语另一点,不用扫描全部索引。
(6)index:Full Index Scan,index与ALL区别为index类型只遍历索引树,这通常比ALL快,因为索引文件通常比数据文件小。也就是说,虽然all和index都是读全表,但是index是从索引中读取的,而all是从硬盘中读的。
(7)ALL:Full Table Scan,将遍历全表以找到匹配的行。

possible_keys

显示可能应用在这张表中的索引,一个或多个。查询涉及到的字段上若存在索引,则该索引将被列出,但不一定被查询实际使用

打个比方:比如高德地图上规划出来的路线,可能有一条,也可能有多条,这些路线都是理论上能够达到目的地的路线,即可能有多种搜索数据的途径,但是你只能走一条路线,实际搜索的路径,也就是实际走的路线就是key。

key(用来表示有没有用到索引)

实际使用的索引。如果为NULL,则没有使用索引。
查询中若使用了覆盖索引,则该索引和查询的select字段重叠。

但是如果索引失效,或者建立了索引但是没有用上,那么key这个字段里面的内容是null。

key_len

表示索引中使用的字节数,可通过该列计算查询中使用的索引的长度。在不损失精度的情况下,长度越短越好。

key_len显示的值为索引字段的最大可能长度,并非实际使用长度,即key_len是根据表定义计算而得,不是通过表内检索出的。

决定key_len的数值的因素:数据库版本+存储引擎+定义的字段类型+是否可以null+字符集编码都会影响到ken_len的使用和计算参考值。

key_len字段能够帮你检查是否充分的利用上了索引。

ref(用来表示怎么用的索引)

显示索引的哪一列被使用了,如果可能的话,是一个常数。哪些列或常量被用于查找索引列上的值

rows

rows列显示MySQL认为它执行查询时必须检查的行数。
当然了,行数是越少越好。

Extra

包含不适合在其他列中显示但十分重要的额外信息
常见常用的一般是以下6个:

(1)Using filesort
(2)using temporary
(3)using index
(4)using where
(5)using join buffer
(6)impossible where

1.出现第一种情况,using filesort,文件类排序,出现这种情况一般是因为你写得sql的order by的顺序没有服用索引的建立顺序,没有保持一致。如果建立索引的顺序为abc,index(a,b,c),那么写sql的时候也要按abc的顺序,order by a,b,c。否则就会出现using filesort。

因为我们知道,索引就是搜索+排序,where之后order by之前是搜索,order by之后是排序。那么我们要考虑的问题就是我们能否用order by的顺序复用索引的顺序,因为:查询中排序的字段,排序字段若通过索引去访问将大大提高排序速度。

2.出现第二种情况using temporary,使了用临时表保存中间结果,MySQL在对查询结果排序时使用临时表。常见于排序 order by 和分组查询 group by。

3.出现第三中情况using index,表示相应的select操作中使用了覆盖索引(Covering Index),避免访问了表的数据行,效率不错!
如果同时出现using where,表明索引被用来执行索引键值的查找;
如果没有同时出现using where,表明索引只是用来读取数据而非利用索引执行查找。
覆盖索引
第一种理解方式:就是select的数据列只从索引中就能够取得,不必读取数据行,MySQL可以利用索引返回select列表中的字段,而不必根据索引再起读取数据文件,话句话说查询列要被所建的索引覆盖。

第二种理解方式:索引是高效找到行的一个方法,但是一般数据库也能使用索引找到一个列的数据,因此它不必读取整个行。毕竟索引叶子节点存储了他们索引的数据,当能通过读取索引既可以得到想要的数据,那就不需要读取行了。一个索引包含了(或覆盖了)满足查询结果的数据就叫做覆盖索引。

4.using where
表明使用了where过滤

5.using join buffer
使用了连接缓存

6.impossible where
where子句的值总是false,不能用来获取任何元组

6.避免索引失效

(1)全值匹配我最爱
(2)最佳左前缀法则
如果索引了多列,要遵守最左前缀法则。指的是查询从索引的最左前列开始并且不跳过索引中的列。
(3)不要在索引列上做任何操作(计算、函数、(自动or手动)类型转换),否则会导致索引失效而转向全表扫描
即:等号左边无计算。
(4)存储引擎不能使用索引中范围条件右边的列
即:范围之后全失效
(5)尽量使用覆盖索引(只访问索引的查询(索引列和查询列一致)),不要使用select*

(6)mysql 在使用不等于(!= 或者<>)的时候无法使用索引会导致全表扫描
(7)如果建表的时候字段定义为NOT NULL,那么sql语句使用is null和is not null 都可能导致索引失效,
如果建表时候字段定义没有not null,那么sql语句使用is null 或者is not null是可以使用索引的。
is not null 也无法使用索引,但是is null是可以使用索引的
(8)like以通配符、下划线开头('%abc...','_abc...')mysql索引失效会变成全表扫描的操作。
即:like百分挂右边。(like的%不能写在两边)。但是,如果检索的时候,搜索的关键字正好覆盖了索引的话,两边都加百分号也是可以不让索引失效的。
(9)字符串不加单引号索引失效
即:varchar引号不可丢。
(10)少用or,用它来连接时会索引失效。如果实际需求中需要用到or,那就用UNION ALL来替代。比如:
select * from table where name = 'abc' or age = 13;
替换成:
select * from table where name = 'abc'
union all
select * from table where age = 13
这个时候既不影响搜索结果又可以利用索引。Tips:这里的union all不可以替换成union,因为UNION会去重,这里要的是不去重的结果。

posted @ 2019-11-03 23:25  craz_cat  阅读(184)  评论(0编辑  收藏  举报