sql优化相关概念,explain的使用说明
文章目录
- 背景
- 查看sql执行效率
- 定位低效率执行SQL
- explain分析执行计划
- explain 之 id
- explain 之 select_type
- explain 之 table
- explain 之 type
- explain 之 key
- explain 之 rows
- explain 之 extra
- show profile分析SQL
背景
在应用的的开发过程中,由于初期数据量小,开发人员写 SQL 语句时更重视功能上的实现,但是当应用系统正式上线后,随着生产数据量的急剧增长,很多 SQL 语句开始逐渐显露出性能问题,对生产的影响也越来越大,此时这些有问题的 SQL 语句就成为整个系统性能的瓶颈,因此我们必须要对它们进行优化,本章将详细介绍在 MySQL 中优化 SQL 语句的方法。
当面对一个有 SQL 性能问题的数据库时,我们应该从何处入手来进行系统的分析,使得能够尽快定位问题 SQL 并尽快解决问题。
查看sql执行效率
MySQL 客户端连接成功后,通过 show [session|global] status 命令可以提供服务器状态信息。show [session|global] status 可以根据需要加上参数“session”或者“global”来显示 session 级(当前连接)的计结果和 global 级(自数据库上次启动至今)的统计结果。如果不写,默认使用参数是“session”。
下面的命令显示了当前 session 中所有统计参数的值:
show status like ‘Com_______’;
show status like ‘Innodb_rows_%’;
Com_xxx 表示每个 xxx 语句执行的次数,我们通常比较关心的是以下几个统计参数。
参数 | 含义 |
---|---|
Com_select | 执行 select 操作的次数,一次查询只累加 1。 |
Com_insert | 执行 INSERT 操作的次数,对于批量插入的 INSERT 操作,只累加一次。 |
Com_update | 执行 UPDATE 操作的次数。 |
Com_delete | 执行 DELETE 操作的次数。 |
Innodb_rows_read | select 查询返回的行数。 |
Innodb_rows_inserted | 执行 INSERT 操作插入的行数。 |
Innodb_rows_updated | 执行 UPDATE 操作更新的行数。 |
Innodb_rows_deleted | 执行 DELETE 操作删除的行数。 |
Connections | 试图连接 MySQL 服务器的次数。 |
Uptime | 服务器工作时间。 |
Slow_queries | 慢查询的次数。 |
Com_*** : 这些参数对于所有存储引擎的表操作都会进行累计。
Innodb_*** : 这几个参数只是针对InnoDB 存储引擎的,累加的算法也略有不同。
定位低效率执行SQL
可以通过以下两种方式定位执行效率较低的 SQL 语句。
- 慢查询日志 : 通过慢查询日志定位那些执行效率较低的 SQL 语句,用–log-slow-queries[=file_name]选项启动时,mysqld 写一个包含所有执行时间超过 long_query_time 秒的 SQL 语句的日志文件。具体可以查看本书第 26 章中日志管理的相关部分。
- show processlist : 慢查询日志在查询结束以后才纪录,所以在应用反映执行效率出现问题的时候查询慢查询日志并不能定位问题,可以使用show processlist命令查看当前MySQL在进行的线程,包括线程的状态、是否锁表等,可以实时地查看 SQL 的执行情况,同时对一些锁表操作进行优化。
1) id列,用户登录mysql时,系统分配的"connection_id",可以使用函数connection_id()查看
2) user列,显示当前用户。如果不是root,这个命令就只显示用户权限范围的sql语句
3) host列,显示这个语句是从哪个ip的哪个端口上发的,可以用来跟踪出现问题语句的用户
4) db列,显示这个进程目前连接的是哪个数据库
5) command列,显示当前连接的执行的命令,一般取值为休眠(sleep),查询(query),连接(connect)等
6) time列,显示这个状态持续的时间,单位是秒
7) state列,显示使用当前连接的sql语句的状态,很重要的列。state描述的是语句执行中的某一个状态。一个sql语句,以查询为例,可能需要经过copying to tmp table、sorting result、sending data等状态才可以完成
8) info列,显示这个sql语句,是判断问题语句的一个重要依据
explain分析执行计划
通过以上步骤查询到效率低的 SQL 语句后,可以通过 EXPLAIN或者 DESC命令获取 MySQL如何执行 SELECT 语句的信息,包括在 SELECT 语句执行过程中表如何连接和连接的顺序。
查询SQL语句的执行计划 :
explain select * from tb_item where id = 1;
字段 | 含义 |
---|---|
id | select查询的序列号,是一组数字,表示的是查询中执行select子句或者是操作表的顺序。 |
select_type | 表示 SELECT 的类型,常见的取值有 SIMPLE(简单表,即不使用表连接或者子查询)、PRIMARY(主查询,即外层的查询)、UNION(UNION 中的第二个或者后面的查询语句)、SUBQUERY(子查询中的第一个 SELECT)等 |
table | 输出结果集的表 |
type | 表示表的连接类型,性能由好到差的连接类型为( system —> const -----> eq_ref ------> ref -------> ref_or_null----> index_merge —> index_subquery -----> range -----> index ------> all ) |
possible_keys | 表示查询时,可能使用的索引 |
key | 表示实际使用的索引 |
key_len | 索引字段的长度 |
rows | 扫描行的数量 |
extra | 执行情况的说明和描述 |
explain 之 id
id 字段是 select查询的序列号,是一组数字,表示的是查询中执行select子句或者是操作表的顺序。id 情况有三种 :
1) id 相同表示加载表的顺序是从上到下。
2) id 不同id值越大,优先级越高,越先被执行。
3) id 有相同,也有不同,同时存在。id相同的可以认为是一组,从上往下顺序执行;在所有的组中,id的值越大,优先级越高,越先执行。
explain 之 select_type
表示 SELECT 的类型,常见的取值,如下表所示:
select_type | 含义 |
---|---|
SIMPLE | 简单的select查询,查询中不包含子查询或者UNION |
PRIMARY | 查询中若包含任何复杂的子查询,最外层查询标记为该标识 |
SUBQUERY | 在SELECT 或 WHERE 列表中包含了子查询 |
DERIVED | 在FROM 列表中包含的子查询,被标记为 DERIVED(衍生) MYSQL会递归执行这些子查询,把结果放在临时表中 |
UNION | 若第二个SELECT出现在UNION之后,则标记为UNION ; 若UNION包含在FROM子句的子查询中,外层SELECT将被标记为 : DERIVED |
UNION RESULT | 从UNION表获取结果的SELECT |
explain 之 table
展示这一行的数据是关于哪一张表的
explain 之 type
type 显示的是访问类型,是较为重要的一个指标,可取值为:
type | 含义 |
---|---|
NULL | MySQL不访问任何表,索引,直接返回结果 |
system | 表只有一行记录(等于系统表),这是const类型的特例,一般不会出现 |
const | 表示通过索引一次就找到了,const 用于比较primary key 或者 unique 索引。因为只匹配一行数据,所以很快。如将主键置于where列表中,MySQL 就能将该查询转换为一个常亮。const于将 “主键” 或 “唯一” 索引的所有部分与常量值进行比较 |
eq_ref | 类似ref,区别在于使用的是唯一索引,使用主键的关联查询,关联查询出的记录只有一条。常见于主键或唯一索引扫描 |
ref | 非唯一性索引扫描,返回匹配某个单独值的所有行。本质上也是一种索引访问,返回所有匹配某个单独值的所有行(多个) |
range | 只检索给定返回的行,使用一个索引来选择行。 where 之后出现 between , < , > , in 等操作。 |
index | index 与 ALL的区别为 index 类型只是遍历了索引树, 通常比ALL 快, ALL 是遍历数据文件。 |
all | 将遍历全表以找到匹配的行 |
结果值从最好到最坏以此是:
NULL > system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALLsystem > const > eq_ref > ref > range > index > ALL
一般来说, 我们需要保证查询至少达到 range 级别, 最好达到ref 。
explain 之 key
possible_keys : 显示可能应用在这张表的索引, 一个或多个。 key : 实际使用的索引, 如果为NULL, 则没有使用索引。key_len : 表示索引中使用的字节数, 该值为索引字段最大可能长度,并非实际使用长度,在不损失精确性的前提下, 长度越短越好 。
explain 之 rows
扫描行的数量。
explain 之 extra
其他的额外的执行计划信息,在该列展示 。
extra | 含义 |
---|---|
using filesort | 说明mysql会对数据使用一个外部的索引排序,而不是按照表内的索引顺序进行读取, 称为 “文件排序”, 效率低。 |
using temporary | 使用了临时表保存中间结果,MySQL在对查询结果排序时使用临时表。常见于 order by 和 group by; 效率低 |
using index | 表示相应的select操作使用了覆盖索引, 避免访问表的数据行, 效率不错。 |
show profile分析SQL
Mysql从5.0.37版本开始增加了对 show profiles 和 show profile 语句的支持。show profiles 能够在做SQL优化时帮助我们了解时间都耗费到哪里去了。
通过 have_profiling 参数,能够看到当前MySQL是否支持profile:
默认profiling是关闭的,可以通过set语句在Session级别开启profiling:
set profiling=1; //开启profiling 开关;
通过profile,我们能够更清楚地了解SQL执行的过程。
首先,我们可以执行一系列的操作,如下图所示:
show databases;
use db01;
show tables;
select * from tb_item where id < 5;
select count(*) from tb_item;
执行完上述命令之后,再执行show profiles 指令, 来查看SQL语句执行的耗时,再获取到最消耗时间的线程状态后,MySQL支持进一步选择all、cpu、block io 、context switch、page faults等明细类型类查看MySQL在使用什么资源上耗费了过高的时间。例如,选择查看CPU的耗费时间 。
字段 | 含义 |
---|---|
Status | sql 语句执行的状态 |
Duration | sql 执行过程中每一个步骤的耗时 |
CPU_user | 当前用户占有的cpu |
CPU_system | 系统占有的cpu |
本文参考www.itheima.com学习资料,只用于本人学习笔记总结,不可转载,如有侵权请谅解。
sql优化相关概念,explain的使用说明相关推荐
- SQL 优化工具 Explain
## SQL优化工具Explain MySQL是关系型数据库中的一种,**查询功能强,数据一致性高,数据安全性高,支持二级索引**.但性能方面稍逊与非关系型数据库,特别是百万级别以上的数据,很容易出现 ...
- sql优化之explain关键字分析
explain是非常重要的关键字,要善于运用它. 通过explain我们可以获得以下信息: 表的读取顺序 数据读取操作的操作类型 哪些索引可以使用 哪些索引被实际使用 表之间的引用 每张表有多少 ...
- 基于explain分析进行SQL优化(实例分析)
背景 最近遇到一个问题,实现相同功能的几个 sql 不知道哪个最优.当然直接测试可以得到最终结论,但是还是不知道为啥慢,为啥快,还可以怎么样再进行优化?这些问题没有解决.下面通过一个实例来介绍下 sq ...
- 面试官:不会看 Explain执行计划,简历敢写 SQL 优化?
来自:程序员内点事 昨天中午在食堂,和部门的技术大牛们坐在一桌吃饭,作为一个卑微技术渣仔默默的吃着饭,听大佬们高谈阔论,研究各种高端技术,我TM也想说话可实在插不上嘴. 聊着聊着突然说到他上午面试了一 ...
- map语法获取index_MySQL SQL语法优化——使用Explain查看执行计划
夜深,最近在写SQL优化的一些文章,看到私聊中,有很多人在问如何判断是否需要优化或者是如何查看MySQL执行计划,本文简要介绍一下MySQL EXPLAIN命令. EXPLAIN命令是查看优化器如何决 ...
- MySQL02--高级(BTreeB+Tree、聚簇索引非聚簇索引、性能分析(Explain)、索引、sql优化)
1.MySQL架构 2.sql 执行顺序: FROM <LEFT_TABLE> ON <JOIN_CONDITION> <JOIN_TYPR> JOIN <R ...
- MySQL数据库性能优化由浅入深(表设计、慢查询、SQL索引优化、Explain分析、Show Profile分析、配置优化)
文章目录 0 SQL性能分析 1 表的设计合理化 1.1 为什么需要范式 1.2 三范式原理 1.3 什么样的表才满足三范式 2 慢查询 2.1 慢查询介绍 2.2 慢查询步骤 3 添加适当索引 3. ...
- SQL索引优化之explain查询计划
前言 最近工作当中使用SQL的场景比较多,遇到了一些瓶颈,在SQL优化这方面做了一些了解. 在SQL应用中影响性能最多的就是慢查询,关于慢查询的优化,主要有这几个着手的方向: 监控sql执行情况,发邮 ...
- 18000字的SQL优化大全,收藏直接起飞!
来源:数据分析不是个事儿 很多朋友在做数据分析时,分析两分钟,跑数两小时? 在使用SQL过程中不仅要关注数据结果,同样要注意SQL语句的执行效率. 本文涉及三部分,篇幅较长,建议收藏后翻看: SQL介 ...
- 18000 字的 SQL 优化大全,收藏直接起飞!
导读:很多朋友在做数据分析时,分析两分钟,跑数两小时?在使用SQL过程中不仅要关注数据结果,同样要注意SQL语句的执行效率. 本文涉及三部分,篇幅较长,建议收藏后翻看: SQL介绍 SQL优化方法 S ...
最新文章
- [Luogu] 聪聪可可
- 三星android5.0基带,三星首款5G手机没用高通!问题来了:5G基带哪家强?
- Linux网络编程 | 零拷贝 :sendfile、mmap、splice、tee
- 老陈学 C++ 序列之二: 友元函数
- 【项目总结】如何获取地图上的所有POI
- Keras-Sequential模型(1)
- python处理HTML的函数库,【整理】关于Python中的html处理库函数BeautifulSoup使用注意事项...
- c语言读取广播星历程序,GPS广播星历计算卫星位置和速度.doc
- 云服务器发现安全漏洞怎么解决?
- Django 数据迁移导入导出
- Matlab视觉处理模块定位控制全向轮小车运动:目标跟踪测试
- 高德地图 调用天地图 WMTS 服务
- BasicVSR_pp video2frame
- 《python编程从入门到实践》第2版 第四章课后练习
- iPhone手机热点连接不稳定
- 线性关系r范围_一个简单线性回归和多项式回归在R中的实现示例
- 什么是真正的资源整合,真正明白此方法后,可借万物为你赚钱!
- git merge和rebase的区别
- 仿支付宝首页下拉刷新
- Coursera SQL for Data Science - Notes