mysql优化实战(explain && 索引)

实验环境:


1、sql工具:Navicat

2、sql数据库,使用openstack数据库作为示例

一、mysql索引查询


show index from instances

结果字段解释:


Table:数据库表名

Non_unique:索引不能包括重复词,则为0。可以,则为1。

Key_name:索引的名称。

索引中的列序列号,从1开始。

列名称

列以什么方式存储在索引中。在MySQL中,有值‘A’(升序)或NULL(无分类)。

索引中唯一值的数目的估计值。通过运行ANALYZE TABLE或myisamchk -a可以更新。基数根据被存储为整数的统计数据来计数,所以即使对于小型表,该值也没有必要是精确的。基数越大,当进行联合时,MySQL使用该索引的机 会就越大。

如果列只是被部分地编入索引,则为被编入索引的字符的数目。如果整列被编入索引,则为NULL。

指示关键字如何被压缩。如果没有被压缩,则为NULL。

如果列含有NULL,则为YES。如果没有,则该列为NO。

用过的索引方法(BTREE, FULLTEXT, HASH, RTREE)。

Comment:注释。

二、验证Mysql的主键会自动创建索引?

创建一个没有主键的ttx_index数据库表:

查询索引:

结果显示没有索引。

改变ttx_index数据库表字段id,将之设为主键,再次查询索引:

得出结论,在Mysql中,数据库主键会自动建立索引。

三、Mysql性能优化利器:explain

1、首先查看instances数据库表的索引:

2、EXPLAIN 用法详解:


EXPLAIN SELECT * FROM instances

根据上述结果,可以此查询花了0.027ms,没有可用的索引。

explain字段详解:

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

type:这是重要的列,显示连接使用了何种类型。从最好到最差的连接类型为const、eq_reg、ref、range、indexhe和ALL

possible_keys:显示可能应用在这张表中的索引。如果为空,没有可能的索引。可以为相关的域从WHERE语句中选择一个合适的语句

key: 实际使用的索引。如果为NULL,则没有使用索引。很少的情况下,MYSQL会选择优化不足的索引。这种情况下,可以在SELECT语句中使用USE INDEX(indexname)来强制使用一个索引或者用IGNORE INDEX(indexname)来强制MYSQL忽略索引

key_len:使用的索引的长度。在不损失精确性的情况下,长度越短越好

ref:显示索引的哪一列被使用了,如果可能的话,是一个常数

rows:MYSQL认为必须检查的用来返回请求数据的行数

Extra:关于MYSQL如何解析查询的额外信息。将在下表中讨论,但这里可以看到的坏的例子是Using temporary和Using filesort,意思MYSQL根本不能使用索引,结果是检索会很慢

extra列返回的描述的意义:

Distinct:一旦MYSQL找到了与行相联合匹配的行,就不再搜索了

Not exists: MYSQL优化了LEFT JOIN,一旦它找到了匹配LEFT JOIN标准的行,就不再搜索了

Range checked for each Record(index map:#):没有找到理想的索引,因此对于从前面表中来的每一个行组合,MYSQL检查使用哪个索引,并用它来从表中返回行。这是使用索引的最慢的连接之一

Using filesort: 看到这个的时候,查询就需要优化了。MYSQL需要进行额外的步骤来发现如何对返回的行排序。它根据连接类型以及存储排序键值和匹配条件的全部行的行指针来排序全部行

Using index: 列数据是从仅仅使用了索引中的信息而没有读取实际的行动的表返回的,这发生在对表的全部的请求列都是同一个索引的部分的时候

Using temporary 看到这个的时候,查询需要优化了。这里,MYSQL需要创建一个临时表来存储结果,这通常发生在对不同的列集进行ORDER BY上,而不是GROUP BY上

Where used 使用了WHERE从句来限制哪些行将与下一张表匹配或者是返回给用户。如果不想返回表中的全部行,并且连接类型ALL或index,这就会发生,或者是查询有问题不同连接类型的解释(按照效率高低的顺序排序)

system 表只有一行:system表。这是const连接类型的特殊情况

const:表中的一个记录的最大值能够匹配这个查询(索引可以是主键或惟一索引)。因为只有一行,这个值实际就是常数,因为MYSQL先读这个值然后把它当做常数来对待

eq_ref:在连接中,MYSQL在查询时,从前面的表中,对每一个记录的联合都从表中读取一个记录,它在查询使用了索引为主键或惟一键的全部时使用

ref:这个连接类型只有在查询使用了不是惟一或主键的键或者是这些类型的部分(比如,利用最左边前缀)时发生。对于之前的表的每一个行联合,全部记录都将从表中读出。这个类型严重依赖于根据索引匹配的记录多少—越少越好

range:这个连接类型使用索引返回一个范围中的行,比如使用>或<查找东西时发生的情况

index: 这个连接类型对前面的表中的每一个记录联合进行完全扫描(比ALL更好,因为索引一般小于表数据)

ALL:这个连接类型对于前面的每一个记录联合进行完全扫描,这一般比较糟糕,应该尽量避免

那么如何才能让sql走索引查询呢?


EXPLAIN SELECT * FROM instances WHERE id=1

从上图可以,该sql语句走了索引。因为该表中id为主键,mysql会自动创建索引,因此当将id作为where条件查询时,数据库会自动走索引。

接下来实验,当不走索引还是查询id=1这条数据时候,会是如何?


SELECT id, display_name FROM instances WHERE id=1


EXPLAIN SELECT * FROM instances WHERE display_name = "vm1"

结论:在查询时候,如果where条件中的字段有索引(走不走索引,取决于where条件中的字段),在执行sql语句时,mysql会自动走索引。

但是有个问题是,在走不走索引,查询花费时间都是0.001ms,似乎没有得到性能提高?


SELECT COUNT(*) FROM instances

在数据库表中instance数据总条数才74条,因此索引没法发挥它的性能优势,接下来人为制造上w条数据:


insert instances(display_name) select display_name from instances

注:上述语句,可用来为数据库表指数形式插入新数据。

再次查询总条数:


SELECT COUNT(*) FROM instances

这次数据已经有接近500w了。

再次验证上述索引性能问题:

1、为了对比的真实性,将id=1的数据记录的display_name修改为唯一名字test_index_dispaly_name


SELECT id, display_name FROM instances WHERE id=1

2、不走索引查询:


SELECT * FROM instances WHERE display_name = ‘test_index_dispaly_name‘

3、通过id走索引查询:


SELECT * FROM instances WHERE id=1

结论:对于百万上亿级数据,走不走索引效率影响相当明显(效率差别都到万了)。

4、哪些情况sql不会走索引?


时间关系,此处暂且未总结,后续有时间补上。若有需要请自行网上查找。
时间: 2024-11-05 16:38:34

mysql优化实战(explain && 索引)的相关文章

(2)mysql优化之使用索引优化查询

概述 ??索引是数据库优化中最常用的也是最重要的手段之一.该篇看看索引的分类,使用场景,不能使用的场景等. 索引分类 ??索引是在mysql存储引擎中实现的,而不是在服务器层实现的.索引每种存储引擎的索引不一定相同.mysql支持4种索引: B-tree索引:最常见索引,大部分引擎都支持B树索引. full-text索引:全文索引. hash索引:只有memory引擎支持. R-Tree索引:空间索引是myisam的一种特殊索引,使用比较少. 衍生索引:主键,唯一索引,组合索引,前缀索引等.ha

MySQL优化之explain

在日常的MYSQL优化中我们常常看到这样一个关键词:explain,例如这种: EXPLAIN SELECT * FROM Cloud_Order WHERE money < 10; explain是什么呢?使用 EXPLAIN 关键字可以模拟优化器执行SQL查询语句,从而知道MySQL是如何处理你的SQL语句的.这可以帮你分析你的查询语句或是表结构的性能瓶颈.通过explain命令可以得到: 表的读取顺序 数据读取操作的操作类型 哪些索引可以使用 哪些索引被实际使用 表之间的引用 每张表有多少

MySQL 优化sql explain执行计划详解

mysql explain执行计划详解 1).id列数字越大越先执行,如果说数字一样大,那么就从上往下依次执行,id列为null的就表是这是一个结果集,不需要使用它来进行查询. 2).select_type列常见的有:A:simple:表示不需要union操作或者不包含子查询的简单select查询.有连接查询时,外层的查询为simple,且只有一个B:primary:一个需要union操作或者含有子查询的select,位于最外层的单位查询的select_type即为primary.且只有一个C:

MySQL优化(2):索引简述

一.基本语法 创建索引前会先排序,会影响where和order by的效率. 索引也是一张表,保存了主键和索引字段和指向实体表的记录,也是要占空间的,以索引文件的形式存储在磁盘. 增删改数据时,索引指向也要改变,所以会慢,需要频繁删改的字段不适合建索引. 索引的建立也需要不断的优化.调整. 1.创建,两种写法 CREATE [UNIQUE] INDEX 索引名 ON 表(列1,列2); 主键索引:ALTER TABLE 表 ADD PRIMARY KEY (列); #添加一个主键,索引值必须唯一

MySQL优化(5):索引失效分析、in与exists使用场合

一.索引失效的情况 前文提及过可以通过explain的possible_keys.key属性判断索引是否失效,key如果为null,可能是索引没建,也可能是索引失效,下面列举一些会使索引失效的情况. 1.全值匹配:顺序.个数与索引一致 2.最佳左前缀法则:查询从索引的最左前列开始并且不跳过索引中的列,中间跳过的值,后面的索引会失效 3.索引列上做了操作(计算.函数.自动或手动类型转换),会导致索引失效而转向全表扫描 4.存储引擎不能使用索引中范围条件右边的列 name字段用于查找,age>11也

Mysql优化系列之索引性能

实际上,前面的数据类型和表结构设计优化不能算优化,只能算规范,也就是说在设计表的时候,应该且必须做到这些 索引是sql优化的核心部分,在<高性能Mysql>中单独抽出一章讲,也印证了其重要性.这一篇也会讲的很细致. 以下所讲,除少数的如全文索引之外,均以Innodb存储引擎为基本 一.索引是什么 索引,在Mysql中也叫做"键(key)",是存储引擎用于快速找到记录的一种数据结构. 这里我们注意到:索引是一种数据结构,节点是有序的,有大小,有时候一张表的索引甚至会有几个G的

Mysql 优化之延迟索引和分页优化

什么是延迟索引?使用索引查询出来数据,之后把查询结果和同一张表中数据进行连接查询,进而提高查询速度! 分页是一个很常见功能,select   **  from tableName limit  ($page -  1 )  * $n ,$n 通过一个存储过程进行测试: create table smth1 ( id int auto_increment , ver int(11) default null, content varchar(1000) not null, intro varcha

Mysql优化之BTree索引使用规则

从一道题开始分析: 假设某个表有一个联合索引(c1,c2,c3,c4)一下--只能使用该联合索引的c1,c2,c3部分 A where c1=x and c2=x and c4>x and c3=x B where c1=x and c2=x and c4=x order by c3 C where c1=x and c4= x group by c3,c2 D where c1=? and c5=? order by c2,c3 E where c1=? and c2=? and c5=? o

mysql优化之索引

Mysql优化之使用索引 1,索引简介 索引是单独一种数据结构,单独存在的一个空间.可以把数据表里的建立了索引的字段,进和物理地址,存在在一块,这块空间就是'索引'. 查询数据先从索引中查询,查询到之后,可以直接定位到物理地址,通过物理地址,直接找到真实数据.查询会更快速. 索引是一种 以空间换时间的一种方式,牺牲了空间和写的速度,提高了查询速度 2,准备演示数据表 这里以myisam引擎的数据库为例,我准备了一张1800000条数据的表,这张表存储时包含了三个文件,.Frm是表结构文件,.MY