mysql执行计划

MYSQL调优总结1

被刻印的时光 ゝ 提交于 2019-11-27 11:45:56
如果一台服务器出现长时间负载过高 /周期性负载过大,或偶尔卡住如何来处理? 答:大的思路-------- 是周期性的变化还是偶尔问题? 是服务器整体性能的问题, 还是某单条语句的问题? 具体到单条语句, 这条语句是在等待上花的时间,还是查询上花的时间. 唯一的办法-----监测并观察服务器的状态. 1:观察服务器状态, 一般用如下2个命令 Show processlist; 这个命令是显示当前所有连接的工作状态. 如果观察到以下状态,则需要注意 converting HEAP to MyISAM 查询结果太大时,把结果放在磁盘 (语句写的不好,取数据太多) create tmp table 创建临时表(如group时储存中间结果,说明索引建的不好) Copying to tmp table on disk 把内存临时表复制到磁盘 (索引不好,表字段选的不好) locked 被其他查询锁住 (一般在使用事务时易发生,互联网应用不常发生) logging slow query 记录慢查询 例: mysql> show status; 查看链接状态 mysql 5.5 以后加了一个profile设置,可以观察到具体语句的执行步骤. 0:查看profile是否开启 > Show variables like ‘profiling’ 1:> set profiling=on; mysql>

MYSQL调优总结1

喜欢而已 提交于 2019-11-27 11:45:43
如果一台服务器出现长时间负载过高 /周期性负载过大,或偶尔卡住如何来处理? 答:大的思路-------- 是周期性的变化还是偶尔问题? 是服务器整体性能的问题, 还是某单条语句的问题? 具体到单条语句, 这条语句是在等待上花的时间,还是查询上花的时间. 唯一的办法-----监测并观察服务器的状态. 1:观察服务器状态, 一般用如下2个命令 Show processlist; 这个命令是显示当前所有连接的工作状态. 如果观察到以下状态,则需要注意 converting HEAP to MyISAM 查询结果太大时,把结果放在磁盘 (语句写的不好,取数据太多) create tmp table 创建临时表(如group时储存中间结果,说明索引建的不好) Copying to tmp table on disk 把内存临时表复制到磁盘 (索引不好,表字段选的不好) locked 被其他查询锁住 (一般在使用事务时易发生,互联网应用不常发生) logging slow query 记录慢查询 例: mysql> show status; 查看链接状态 mysql 5.5 以后加了一个profile设置,可以观察到具体语句的执行步骤. 0:查看profile是否开启 > Show variables like ‘profiling’ 1:> set profiling=on; mysql>

结合explain extended浅析使用mysql in 的效率

不打扰是莪最后的温柔 提交于 2019-11-27 11:45:11
用explain extended查看执行计划会比explain多一列 filtered。 filtered列给出了一个百分比的值,这个百分比值和rows列的值一起使用,可以估计出那些将要和explain中的前一个表进行连接的行的数目。 前一个表就是指explain 的 id列的值比当前表的id小的表。 1. mysql sql查询中,in是会走索引的: 点击( 此处 )折叠或打开 mysql > explain extended select * , sleep ( 0 . 2 ) from testinfo where id in ( 1232 , 232 , 324 , 2342 , 23 ) ; + - - - - + - - - - - - - - - - - - - + - - - - - - - - - - + - - - - - - - + - - - - - - - - - - - - - - - + - - - - - - - - - + - - - - - - - - - + - - - - - - + - - - - - - + - - - - - - - - - - + - - - - - - - - - - - - - + | id | select_type | table | type | possible_keys | key | key_len

《高性能MySQL》读书笔记之MySQL 优化

痴心易碎 提交于 2019-11-27 11:43:39
关于MySQL的执行过程: 1 MySQL中存在对SQL语句的改写,通过改写SQL达到优化SQL语句的目的,如将子查询改为关联查询. 2 MySQL并没有像Oracle 11g那样缓存执行计划,在Java开发中PreparedStatement接口对SQL进行预编译在默认情况下并没有发生.(即使开启也是在JDBC端缓存,数据库中并未缓存执行计划) 3 MySQL通讯协议是单向的,不同于Oracle.因为这一点,JDBC端只有在接收到所有查询结果后才会进行下一步操作.即在JDBC操作中只取出一条数据然后关闭ResultSet的做法,实际上并不会减轻网络通信负担. 4 MySQL会缓存查询结果,同时MySQL的连接和断开是轻量级的,所以在多数情况下,将一个复杂的查询切分为几个简单查询是非常有意义的. *5 很多人认为where后面的条件顺序影响执行结果.在Oracle下因为会解析语方树,所以肯定是不会有影响的(Oracle解析语方树是从后往前解析的,之后再生成执行计划,所以存在两个错误的情况下后面的错误先报出来,会给人后面的语句先执行的错觉). 个人认为因为MySQL也存在SQL优化,所以不会有影响.实际情况中确实会有影响,这是因为统计信息,估算成本不够准确,优化器认为两个条件约束力是相同的,所以按书写计划来执行.以上是本人关点未经验证. 关于性能测试: select * from

MYSQL explain详解

放肆的年华 提交于 2019-11-27 11:42:52
explain显示了 MySQL 如何使用索引来处理select语句以及连接表。可以帮助选择更好的索引和写出更优化的查询语句。 先解析一条sql语句,看出现什么内容 EXPLAINSELECTs.uid,s.username,s.name,f.email,f.mobile,f.phone,f.postalcode,f.address FROM uchome_space ASs,uchome_spacefieldASf WHERE 1 AND s.groupid=0 AND s.uid=f.uid 1. id SELECT识别符。这是SELECT查询序列号。这个不重要,查询序号即为sql语句执行的顺序,看下面这条sql EXPLAINSELECT*FROM( SELECT* FROMuchome_space LIMIT10)ASs 它的执行结果为 可以看到这时的id变化了 2.select_type select类型,它有以下几种值 2.1 simple 它表示简单的select,没有union和子查询 2.2 primary 最外面的select,在有子查询的语句中,最外面的select查询就是primary,上图中就是这样 2.3 union union语句的第二个或者说是后面那一个.现执行一条语句,explain select * from uchome_space limit

mysql 优化步骤

谁说我不能喝 提交于 2019-11-27 11:42:38
优化SQL语句的一般步骤: 1. 通过 show status 命令了解各种SQL的执行效率。 show status like 'com_%' Com_xxx表示每个xxx语句执行的次数,我们通常比较关心的是一下几个参数: Com_select: 执行SELECT 操作的次数,一次查询累加1 Com_insert: 执行INSERT 操作的次数,对于批量插入的INSERT操作,只累加一次。 Com_updata: 执行UPDATA 操作的次数。 Com_delete: 执行DELETE 操作的次数。 可以很容易地了解当前数据库的应用是以插入更新为主还是以查询操作为主,以及各种 数据类型的SQL大致的执行比例是多少。对于更新操作的计数,是对执行次数的计数, 不是提交还是回滚都会进行累加。 对于事务型的应用,通过Com_commit和Com_rollback 可以了解事务提交和回滚的情况, 对于回滚操作非常频繁的数据库,可意味着应用编写存在问题。 此外,以下几个参数便于用户了解数据库的基本情况。 connections: 试图连接mysql服务器的次数。 Uptime: 服务器工作时间。 Slow_queries: 慢查询的次数。 2. 定位执行效率较低的SQL语句 1)通过慢查询日志定位那些执行效率较低的SQL语句. 慢查询日志记录了所有执行时间超过参数long_query

MySQL 索引选择原则

自古美人都是妖i 提交于 2019-11-27 11:42:22
目的 MySQL 查询优化器是基于代价( cost-based )的查询方式。因此,在查询过程中,最重要的一部分是根据查询的 SQL 语句,依据多种索引,计算查询需要的代价,从而选择最优的索引方式生成查询计划。 然而,在分析 MySQL 查询优化器过程中,是以查询优化器主线的原则进行研究,而忽略了很多细节的内容。因此,对 MySQL 索引选择进行进一步的研究和分析,给出创建和使用索引的规则,从而有助于分析 SQL 查询。 设计 设计原则主要依据为尽可能的测试索引,而不考虑索引的合理性。一方面可以更加全面的测试在多种索引存在的情况下,查询优化器是如何进行选择的。另一方面可以根据选择索引的原则,评估索引的合理性。 1 、数据表设计 数据表设计如下所示,其中 students_origin 表中只有主键索引, students 表设计主键索引( Primary Key )、唯一索引( Unique Key )、 B+ 索引、联合索引等。 点击( 此处 )折叠或打开 CREATE TABLE `students_origin` ( `id` int ( 11 ) NOT NULL , `name` varchar ( 30 ) DEFAULT NULL , `age` int ( 11 ) DEFAULT NULL , `major` varchar ( 20 ) DEFAULT NULL

Mysql索引分析

主宰稳场 提交于 2019-11-27 11:42:09
这里主要利用explain来观察语句是否走索引。 explain语法自行百度,详见Mysql官方文档。 一、explain输出格式说明 具体说明: 1) id 该字段标识select语句id,若SQL中只有1个select语句(即使是多表关联查询),则该值为1,否则依次递增;若SQL是union的结果,则该值为NULL。 2) select_type 该字段说明select语句的类型,其可能的取值如下图(来自官网文档): 其中,simple是最常见的类型,表明SQL只包含1个select语句;derived表明该行代表的数据表(derived table)其实是from子句中包含的子查询的输出结果;其余类型较易理解, 阅读 官方文档即可,这里不赘述。 3) table 该字段表明explain输出的每行所代表的数据集来自哪张表,其值通常是具体的表名,当数据集是union的结果时,其值可能 是<unionM,N>,当数据集来自derived table时,其值可能是<derivedN>。这里提到的M或N均是id字段的值。 4) type 该字段表明各表是如何被join的,其取值比较复杂,详细可参考官网文档。这里只列出最常见的几种取值。 a. system/const const表明上述"table"字段代表的数据集中,最多只有1行记录命中本步执行计划的查询条件

开发人员MySQL调优-实战篇0-explain详解

走远了吗. 提交于 2019-11-27 11:41:56
本来应该先发这篇的,现在才发现漏掉了 项目中SQL优化流程 ​ 1.开发人员具备一定的SQL优化基本功 ​ 2.在开发阶段,每条写的SQL在测试环境看看他的执行计划 ​ 3.上线后让DBA收集查询比较慢的SQL ​ 4.通过explain工具和show profile 分析慢SQL,修改代码,重新上线,重新收集。如果贵公司的DBA关系和你很好,在优化的时候可以拉他一起,多学点理论和经验 ​ 5.数据库参数调优 ​ 6.操作系统调优 ​ 7.更换硬件设备 查询优化器 ​ MySQL有专门负责SELECT的优化器模块,根据先前收集到的统计信息,为SQL生成一条它认为最优的执行计划,但该计划不一定是DBA认为最优的。也就是说它有可能根据错误的统计信息生成了自认为合理的执行计划。这种时候需要DBA介入,重建索引——》重新收集统计信息,这样MySQL才可能按照真正最优的方式运行,如果MySQL还是不能生成想要的执行计划,DBA还可以固化执行计划 查看机器瓶颈 ​ 使用top、free、iostat、vmstat命令查看机器的硬件资源负载情况 执行计划 ​ 执行计划是MySQL对SQL的执行生成的一套优化策略,以效率为首要目的,提升SQL执行的速度 ​ 可以在MySQL中使用explain SQL或者desc SQL来生成执行计划,如: ​ 有了执行计划能干嘛? ​ 1.查看表的读取顺序 ​

mysql中SQL执行过程详解

半腔热情 提交于 2019-11-27 11:41:42
mysql执行一个查询的过程,到底做了些什么: 客户端发送一条查询给服务器; 服务器先检查查询缓存,如果命中了缓存,则立刻返回存储在缓存中的结果。否则进入下一阶段。 服务器段进行SQL解析、预处理,在优化器生成对应的执行计划; mysql根据优化器生成的执行计划,调用存储引擎的API来执行查询。 将结果返回给客户端。 实际上mysql执行的每一步都比较复杂,具体的过程如下 第一步 : mysql客户端和服务器通讯 1. 通讯 mysql客户端和服务器之间的通讯协议是“半双工”的,这意味着,在任何一个时刻,要么由服务器向客户端发送数据,要么由客户端向服务器发送数据,这两个动作不能同时发生。这种协议让mysql通信简单快速,但也限制了mysql。一个明显的限制是,这意味着没办法进行流量限制。一旦一端开始发生消息,另一端要接收完整个消息才能响应他。 客户端用一个单独的数据包将查询传给服务器。一旦客户端发送了请求,他能做的事情就只是等待结果了。 相反的,一般服务器响应给用户的数据通常很多,由多个数据包组成。当服务器开始响应客户端请求时,客户端必须完整的接受整个返回结果,而不是简单的只收取前面几条结果,然后让服务器停止发送数据。 多数连接mysql的库函数都可以获得全部结果并缓存到内存里,还可以逐行获取所需要的数据。默认一般是获得全部结果并缓存到内存中