mysql执行计划

sql 语句性能分析 1、看 sql 语句执行时间 2、看 sql 的执行计划 3、查看 sql 的执行中各个环节耗时时间 4、查看mysql的执行进程，处理锁表的情况，命令 show PROCESSLIST， state 为LOCKED，说明产生锁表，ID为进程id，直接执行kill ID，就可以停止这个进程； MySQL整个查询执行过程： 1、客户端同数据库服务层建立TCP连接。2、客户端向MySQL服务器发送一条查询请求。3、连接线程接收到SQL语句之后，将语句交给SQL语句解析模块进行语法分析和语义分析。4、先看查询缓存中是否有结果，如果有结果可以直接返回给客户端。5、如果查询缓存中没有结果，就需要真的查询数据库引擎层了，于是发给SQL优化器，进行查询的优化，生成相应的执行计划。6、MySQL根据执行计划，调用存储引擎的API来执行查询7、使用存储引擎查询时，先打开表，如果需要的话获取相应的锁。 查询缓存页中有没有相应的数据，如果有则可以直接返回，如果没有就要从磁盘上去读取。8、当在磁盘中找到相应的数据之后，则会加载到缓存中来，从而使得后面的查询更加高效，由于内存有限，多采用变通的LRU表来管理缓存页，保证缓存的都是经常访问的数据。9、最后，获取数据后返回给客户端，关闭连接，释放连接线程。 Procedure Analyse优化表结构 PROCEDURE ANALYSE()

Explain 是什么? 简称 执行计划 ，使用 explain 关键字可以模拟优化器执行sql查询语句，从而知道Mysql是如何处理你的sql语句的，分析你的查询语句或是表结构性能 瓶颈 举个例子 explain select * from nsi_post_category_item ci where exists ( select 1 from nsi_post_category pc where ci . parent_id = pc . id ) and is_check = 1 id(查询序列号) 选择标识符,select查询序列号 id相同时，执行顺序相同，id值 越大 优先级 越高 ，越先被执行 select_type(查询类型) 展示查询中每个select子句的类型 SIMPLE 简单select，不使用union或子查询等 PRIMARY 子查询中最外层查询，查询中若包含任何复杂的子部分，最外层的select被标记为PRIMARY UNION 若第二个select出现在union之后，则被标记为UNION SUBQUERY 在select中或where中使用了子查询 DERIVED 若第二个select出现在union之后，则被标记为UNION，若union包含在FROM子句的子查询中，外层select被标记为(衍生) UNION RESULT

　　前面讲了如何设计数据库表结构、存储引擎、索引优化等内存，这篇文章会讲述如何进行SQL优化，也是面试中关于数据库肯定会被问到的， 这些内容不仅仅是为了面试，更重要的是付诸实践，最终用到工作当中 　　之前的MySQL内存地址： MySQL系列内容 如何获取存在性能的SQL： 1、通过生产环境用户、测试人员反馈的应用响应速度较慢，可能就是SQL性能较差导致的 2、通过慢查询日志获取 3、实时获取存在性能问题的SQL MySQL慢查日志： 参数： 　　1、slow_query_log　　是否启动慢查询日志，默认不开启，on/off，动态参数，运行时通过set global slow_query_log=on设置，也可以 通过脚本定时开关 　　2、slow_query_log_file　　日志存储和数据存储的文件名和路径，最好是自己设置，而不是默认，日志和数据文件要区分开 　　3、long_query_time　　慢查询日志SQL执行时间的阈值，单位s，默认10s，超过这个执行时间的SQL都会被记录下来，无论是查询还是修改， 还是记录已经回滚的SQL，最大精确到微妙ms，可以设置为1s比较合适 　　4、log_queries_not_using_indexes　　是否记录未使用索引的SQL 设置参数： 　　1、my.cnf，永久生效 　　2、通过SET GLOBAL设置参数，例如SET

一、关于数据库性能分析 数据库服务器的性能： 我们将 性能定义为完成某件任务所需要的时间 ，性能即 响应时间 ，这是应该很重要的原则， 我们通过任务的响应时间而不是资源来测量时间。 性能：即完成任务的响应时间,单位时每个任务花费的时间。 任务：查询或者语句，如SELECT、UPDATE、DELETE。 所以 我们优化时，首先要知道，时间花在哪些地方 。这是第二个原则。 性能剖析： 任务花费时间分为：执行时间和的等待时间。 优化执行时间：通过测量定位不同的子任务花费的时间，然后优化去掉一些子任务，降低子任务的执行频率或者提升子任务的效率。 等待时间：多种原因引起，分析更为复杂。 性能剖析的一般步骤： 1.测量所花费的时间，使用查询日志。 2.然后对结果进行统计和排序，将重要的任务排到前面。 1.采集查询日志 我们如果要测量查询语句所花费的时间，就要捕获Mysql的查询到日志文件中。 Mysql为我们提高了以下的日志来捕获查询： 慢查询日志：io开销低，测量精度最高的查询时间的工具。 通用日志：很少用于分析查询，不包含响应时间和执行计划。 注意：长期开启慢日志，需要消耗大量的磁盘空间，需要部署日志轮转工具，或者只在需要采集查询的时候开启。 Mysql5.1及以后的版本，可以通过设置long_query_time为0来捕获所有的查询，查询的响应单位为微秒级。 2.分析查询日志 分析时

Index Merge特性 在MySQL 5.5之前版本中，查询或子查询被限制在一个表只能使用一个索引(回表查询除外)。 假设表TB1001上C1和C2列分别有单列索引，如对下面查询： SELECT * FROM TB1001 WHERE C1='XXX' OR C2='XXX'; 单独使用任一索引都无法获取到所有满足条件的数据，因此查询只能使用全表扫描。 在MySQL 5.5版本中引入Index Merge特性，允许： 查询对一个表上多个索引进行范围扫描并将多个扫描结果进行合并(UNION/INTERSECT)。 Index Merge三种合并算法： 1、Index Merge Intersect：对多个结果集求交集 2、Index Merge Union：对多个结果集求UNION集合(无需对结果集排序) 3、Index Merge Sort-Union：对多个结果集先排序再求UNION集合 Index Merge Intersect算法 当查询过滤条件(WHERE部分)上使用AND关联多个不同KEY的过滤条件时，如： # 表TB1001有主键索引PRIMARY KEY(ID) # 表TB1001有辅助索引IDX_C1(C1) 和辅助索引IDC_C2(C2) SELECT * FROM TB1001 WHERE C1='XXX' AND C2='XXX'; 不使用Index

1、EXPLAIN 做MySQL优化，我们要善用EXPLAIN查看SQL执行计划。 下面来个简单的示例，标注（1、2、3、4、5）我们要重点关注的数据： type列 ， 连接类型。一个好的SQL语句至少要达到range级别。杜绝出现all级别。 key列， 使用到的索引名。如果没有选择索引，值是NULL。可以采取强制索引方式。 key_len列， 索引长度。 rows列， 扫描行数。该值是个预估值。 extra列， 详细说明。注意，常见的不太友好的值，如下：Using filesort，Using temporary。 2、SQL语句中IN包含的值不应过多 MySQL对于IN做了相应的优化，即将IN中的常量全部存储在一个数组里面，而且这个数组是排好序的。但是如果数值较多，产生的消耗也是比较大的。再例如：select id from t where num in(1,2,3) 对于连续的数值，能用between就不要用in了；再或者使用连接来替换。 3、SELECT语句务必指明字段名称 SELECT*增加很多不必要的消耗（CPU、IO、内存、网络带宽）；增加了使用覆盖索引的可能性；当表结构发生改变时，前断也需要更新。所以要求直接在select后面接上字段名。 4、当只需要一条数据的时候，使用limit 1 这是为了使EXPLAIN中type列达到const类型 5

参考网站： http://www.liyblog.top/p/6 这里总结了52条对sql的查询优化，下面详细来看看，希望能帮助到你 1， 对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。 2，应尽量避免在 where 子句中对字段进行 null 值判断，创建表时NULL是默认值，但大多数时候应该使用NOT NULL，或者使用一个特殊的值，如0，-1作为默 认值。 3，应尽量避免在 where 子句中使用!=或<>操作符， MySQL只有对以下操作符才使用索引：<，<=，=，>，>=，BETWEEN，IN，以及某些时候的LIKE。 4，应尽量避免在 where 子句中使用 or 来连接条件， 否则将导致引擎放弃使用索引而进行全表扫描， 可以 使用UNION合并查询： select id from t where num=10 union all select id from t where num=20 5，in 和 not in 也要慎用，否则会导致全表扫描，对于连续的数值，能用 between 就不要用 in 了：Select id from t where num between 1 and 3 6，下面的查询也将导致全表扫描：select id from t where name like ‘%abc%’

参考网站： http://www.liyblog.top/p/6 这里总结了52条对sql的查询优化，下面详细来看看，希望能帮助到你 1， 对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。 2，应尽量避免在 where 子句中对字段进行 null 值判断，创建表时NULL是默认值，但大多数时候应该使用NOT NULL，或者使用一个特殊的值，如0，-1作为默 认值。 3，应尽量避免在 where 子句中使用!=或<>操作符， MySQL只有对以下操作符才使用索引：<，<=，=，>，>=，BETWEEN，IN，以及某些时候的LIKE。 4，应尽量避免在 where 子句中使用 or 来连接条件， 否则将导致引擎放弃使用索引而进行全表扫描， 可以 使用UNION合并查询： select id from t where num=10 union all select id from t where num=20 5，in 和 not in 也要慎用，否则会导致全表扫描，对于连续的数值，能用 between 就不要用 in 了：Select id from t where num between 1 and 3 6，下面的查询也将导致全表扫描：select id from t where name like ‘%abc%’

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 在讲这个问题之前，说一种现象，大家可能会经常遇到这样的情况感觉数据库好慢啊，数据库cpu咋这么高，内存好像不够用了，应该咋办呢，很多同学一脸茫然，也有少部分同学能说建索引，读写分离，分库分表这样大而化之的优化策略，那具体到执行层面如何细化呢？相信绝大多数测试同学已经进入盲区，数据库的优化是从定性到定量的过程，比如是否沿着索引查询，扫描减少了多少行，文件排序减少没，tps提升多少等等，今天就从sql本身给大家剖析数据库执行计划。 数据库执行计划是啥意思？在我看来，就是告诉我这条sql需要做什么，它是怎么做的，通过执行计划我们能分析出sql的性能以及改进思路。我们以主流的mysql为例，给大家举例如何做执行计划； 在mysql中，执行计划在sql语句前加上explain即可，如图1，大家已经看到出现了很多行， 图1 我先逐行解释下字面意思 Id 代表select语句的编号，相当于标识作用； Select_type 查询类型，常见的例如：simple（不含子查询），primary（含子查询或派生查询）； Table 所查询的表； Partitions 一般查看表分区情况； Type 查询方式，数据库性能诊断的重要依据，一般有all,index,ref,eq_ref,这一行是重点，大家先记住很重要！ Possible

前言 优化有风险，涉足需谨慎！！！ 1、优化可能带来的问题？ 优化不总是对一个单纯的环境进行，还很可能是一个复杂的已投产的系统。 优化手段本来就有很大的风险，只不过我们可能没有能力意识到和预见到！ 任何的技术可以解决一个问题，但必然存在带来一个问题的风险！ 对于优化来说解决问题而带来的问题，控制在可接受的范围内才是有成果，保持现状或出现更差的情况都是失败。 2、优化的需求 稳定性和业务的持续性，通常比性能更重要。 优化不可避免涉及到变更，变更就有风险。 优化使性能变好，维持和变差使等概率事件。 切记优化，应该是各部门协同参与的工作，任何单一部门都不能对数据库进行优化。 所有优化工作，是由业务需要驱使的。 3、优化由谁参与 在进行数据库优化时，应该由DBA、业务部门代表、应用程序设计人员、应用程序开发人员、运维等相关人员共同参与。 4、优化思路 在数据库优化上由两个主要方面：即安全与性能。 安全：数据可持续性。 性能：数据的高性能访问。 5、优化的范围有哪些？ 存储、主机和操作系统方面： 主机架构稳定性； I/O规划及配置； Swap交换分区； OS内核参数和网络问题； 应用程序方面； 应用程序稳定性； SQL语句性能； 串行访问资源； 性能欠佳会话管理； 这个应用适不适合用MySQL； 数据库优化方面： 内存； 数据库结构（物理&逻辑）； 实例配置； 注：不管是在设计系统