学习
实践
活动
工具
TVP
写文章

SQL优化 MySQL版 -分析explain SQL执行计划

教师证表 现在我把这三张表连起来查,查询条件:查询课程编号为2或教师证编号为3点老师信息; 通过这个例子,我们就可以把explain里面的参数一个一个的讲讲: 首先这个条件的主干是查询老师信息; sql JOIN teachercarid te WHERE t.tid = c.cid AND t.tcid = te.tcid AND (c.cid = 2 or te.tcid = 3); 执行结果: SQL (c.cid = 2 or te.tcid = 3); 执行看结果: 先看id: id此时此刻都是1,它们都对应我们的表 te 是我们的教师证表 t 就是教室表 c 是课程表 由此可见,我们编写的SQL 我们不妨来做个试验看看,我再加几条数据: 现在我们的数据变更为: course:课程表 有三条数据 teacher:教师表 有四条数据 teacherCarid:教师证表 有六条数据; 我们再看它的执行计划 中的子查询(最外层) SUBQUERY:包含子查询SQL中的子查询(非最外层) Simple:简单查询(一个SQL语句里面不包含子查询,union)都是简单查询 derived:衍生查询 触发子衍生查询只有两种

7610

SQL优化 MySQL版 -分析explain SQL执行计划与Extra

注:此文章必须有一定的MySQL基础,或观看执行计划入门篇传送门: https://www.linuxidc.com/Linux/2019-03/157264.htm 终于总结到哦SQK执行计划的最后一个知识点了 : Extra Extra有以下几个值,它们都非常重要,它们表示你的SQL语句的最终性能,以下将介绍它的几种值,每个值都代表你的SQL语句的缺陷: 1.Using filesort 主要出现在 order 如: select test01 where a = '3' order by a; 执行结果: 如果没出现那就表明你这个SQL没毛病很显然上图我没出现,如果出现出现这个,说明你当前SQL语句需要“额外 (1,2,3) group by a; 我根据a查询,我又根据a分组,这样就不会出现Useing temporary,这里我也不放图了; 如果我非要让他Useing temporary出现也不难,就把sql 语句很显然,age在索引里面,但是name 不在索引里,这种情况就必须回原表,并且会显示Using where; SQL语句:EXPLAIN SELECT a,d FROM test01 where a

7410
  • 广告
    关闭

    年末·限时回馈

    热卖云产品年终特惠,2核2G轻量应用服务器6.58元/月起,更多上云必备产品助力您轻松上云

  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    Explain 执行计划SQL优化

    执行计划用来显示对应语句在MySQL中是如何执行的。 Explain语句对select,delete,update,insert,replace语句有效。 常见于主键或唯一索引扫描的多表链接操作中 system:当MySQL对查询某部分进行优化,并转换为一个常量时,使用这些类型访问。 其他数据库也叫做唯一索引扫描 NULL:MySQL优化过程中分解语句,执行时甚至不用访问表或索引 possible_keys列 表示MySQL能使用哪个索引在表中找到行,查询涉及到的字段上若存在索引 SQL 优化原则 尽可能消除全表扫描,除非表数据量是在万条一下 增加适当的索引能提高查询的速度,但增加索引需要遵循一定的基本规则: a.   #  慢查询文件存放位置 long_query_time= 2 #2秒以上的语句被记录 慢查询日志并不是只是记录的查出select 语句 ,dml 对数据语句都会记录 SQL 优化测试 创建一个有索引的表

    9220

    Postgresql_根据执行计划优化SQL

    优化实例 慢SQL:select c_ajbh, c_ah, c_cbfy, c_cbrxm, d_larq, d_jarq, n_dbjg, c_yqly from db_zxzhld.t_zhld_db Sql有个缺点就是我不知道查询的字段是从那个表里面取的、建议加上表别名.字段。 查看该sql的表的数据量: db_zxzhld.t_zhld_db :db_zxzhld.t_zhld_ajdbxx :db_zxzhld.t_zhld_zbajxx : 执行计划: Limit Semi Join,actual time=277.794..88932.662, 表db_zxzhld.t_zhld_db dbxx和db_zxzhld.t_zhld_ajdbxx均是全表扫描 具体优化步骤 等价改写SQL(1) 等价改写:将排序条件加入db_zxzhld.t_zhld_ajdbxx让其先排序,再和t_zhld_db表连接。

    14020

    轻松搞懂mysql执行计划,再也不怕sql优化

    近期要做一些sql优化的工作,虽然记得一些常用的sql 优化技巧,但是在工作中还是不够,所以需要借助工具的帮助,数据库的解释计划阐明了sql的执行过程,展示了执行的细节,我们只要根据数据库告诉我们的问题按图索骥的分析就好了 sql。 12、extra 常见的有下面几种 use filesort:MySQL需要额外的一次传递,以找出如何按排序顺序检索行,如果是这个值,应该优化索引。 当查询只使用作为单一索引一部分的列时,可以使用该策略 use where:where子句用于限制哪一行 4、总结 sql 优化的原则就是在保证正确的情况下缩短时间,目标是确定的,通过目标进行回推可以知道想要执行的快就要尽可能的少读数据 看懂解释计划每个字段的就知道sql 的执行路径,结合自己的原则进行优化,祝你好运。

    23130

    MySQLSQL执行计划详解

    MySQL执行计划sql语句经过查询优化器后,查询优化器会根据用户的sql语句所包含的字段和内容数量等统计信息,选择出一个执行效率最优(MySQL系统认为最优)的执行计划,然后根据执行计划,调用存储引擎提供的接口 但是,在MySQL执行的时候,到底使用了一个什么样的执行计划,有没有用到索引。当数据规模比较大的时候,sql执行的时候,执行计划不同,会直接影响sql的执行速度。 这个时候,就需要对sql语句执行进行调试。 MySQL我们在调试sql语句的时候,不会像我们写Java或者其他语言代码那样通过打断点的方式进行代码调试。 这个时候,我们就需要通过查看执行计划来调试我们的sql了。MySQL通过EXPLAIN来查看执行计划,我们写sql语句的时候,在语句之前加一个EXPLAIN就可以了。 包含mysql对于query优化的时候的一些附加信息。非常有用。

    12120

    SQL执行计划优化器相关Hint

    ALL_ROWS 说明: ALL_ROWS是针对整个目标SQL的Hint,它的含义是让优化器启用CBO,而且在得到目标SQL执行计划时会选择那些吞吐量最佳的执行路径。 FIRST_ROWS(n) 说明:FIRST_ROWS(n)是针对整个目标SQL的Hint,它的含义是让优化器启用CBO模式,而且在得到目标SQL执行计划时会选择那些得以最快响应并返回头n条记录的执行路径 ,也就是说在FIRST_ROWS(n) Hint生效的情况下,优化器会启用CBO,而且会依据返回头n条记录的响应时间来决定目标SQL执行计划。 一是因为Oracle早就不支持RBO了,二是因为启用RBO后优化器在执行目标SQL时选择的执行路径将大大减少,很多执行路径RBO根本就不支持(比如哈希连接),这也就意味着启用RBO后目标SQL跑出正确执行计划的概率将大大降低 使用提示first_rows(9),带来的变化就是优化器对基数的估算不同。注意观察执行计划中的Rows部分。

    58840

    Mysql SQL优化

    SQL优化规则 第一条: 尽量全值匹配,也就是说尽量使用等于 第二条: 最佳左前缀原则 如果是复合索引,要遵守最佳左前缀原则,指的是从最左侧列开始并且不跳过索引中的列 如果是按顺序使用的索引列,且有最左侧的列 中间有范围查询会导致后面的索引列全部失效,但是本身是有效的 第五条: 尽量使用覆盖索引 尽量使用覆盖索引(只访问索引的查询(索引列和查询列一致)),减少select * 第六条: 尽量不使用不等于 mysql pos from staffs where name like '%july%' 第九条: 字符串类型加引号 字符串不加单引号索引失效 解决方式:请加引号【捂脸】 第十条: OR改 UNION效率高 这个SQL 优化有诀窍 听着还挺带劲 最后附上习题一部,不发答案,大家自己瞅瞅,可以答案写评论区,我是全猜对了,你呢 ? 作者:彼岸舞 时间:2020\07\11 内容关于:Mysql 本文来源于网络,只做技术分享,一概不负任何责任

    24131

    深入解读SQL优化中的执行计划

    数据库的执行计划SQL优化的最重要手段,执行计划怎么来的、包含什么内容、我们应该关注哪些点,这些是需要我们掌握的,基于这些知识再去理解SQL优化将更加容易。 在SQL前面加上Explain,就可以直接看到执行计划。不管是在pgadmin还是其它工具都可以简单进行查看。 那么这里也是为什么PG在和MySQL比的时候,说它的分析能力要强一点的原因,因为我们的Hash join支持非常好。另外现在MySQL已经支持Hash了,但是还不是那么完善。 最后看执行计划之外,从执行计划去反推SQL优化方向。从最底层一个扫描去入手,要尽量走索引扫描。另外索引扫描这里有很多方式,就是看它是否是合理索引,要看类型是不是选择合理的。 另外还需要减少不必要的索引、避免单条SQL插入,要单条变为批量进行插入。 前面说执行计划表连接类型是不是正确合理,另外要从SQL本身进行入手,我们目的是为了减少它的消耗。

    24340

    SQL优化案例-从执行计划定位SQL问题(三)

    SQL出现问题,能从执行计划中快速的定位哪部分出现问题很重要,SQL文本如下(为保证客户隐私,已经将注释和文字部分去掉): SELECT /*+ index(i IDX_INVM_BEC)*/ RQ, 行数据,查看ID18谓词信息 18 - filter(("SJJGM"='1700' OR "JGM"='1700')) 从这部分再回到SQL文本寻找SQL代码是AND I.BRANCH_NO IN ( 按照上面的分析思路看ID4里面的执行计划都很正确,但是返回结果184行记录且ID4和ID15做nested loop,导致整个view部分缓慢。 那么就很好办了,ID4和ID15应该走hash join,查看outline data信息,还没办法使用db_name信息引导执行计划走hash join,那么只能改写SQL。 由13分钟变为5秒钟执行完,看ID19还要执行999k次,查询ID18谓词信息对应SQL如下,确实是要返回999k行数据。

    24760

    MySQL——通过EXPLAIN分析SQL执行计划

    MySQL中,我们可以通过EXPLAIN命令获取MySQL如何执行SELECT语句的信息,包括在SELECT语句执行过程中表如何连接和连接的顺序。 rows: 扫描行的数量 filtered: 存储引擎返回的数据在server层过滤后,剩下多少满足查询的记录数量的比例(百分比) Extra: 执行情况的说明和描述,包含不适合在其他列中显示但是对执行计划非常重要的额外信息 MySQL5.6引入了**Index Condition Pushdown(ICP)**的特性,进一步优化了查询。Pushdown表示操作下放,某些情况下的条件过滤操作下放到存储引擎。 在5.6版本之后: MySQL使用了ICP来进一步优化查询,在检索的时候,把条件customer_id>=300 AND customer_id<=400也推到存储引擎层完成过滤,这样能够降低不必要的IO Extra为Using index condition就表示使用了ICP优化

    24740

    MySQL——通过EXPLAIN分析SQL执行计划

    MySQL中,我们可以通过EXPLAIN命令获取MySQL如何执行SELECT语句的信息,包括在SELECT语句执行过程中表如何连接和连接的顺序。 ? rows: 扫描行的数量 filtered: 存储引擎返回的数据在server层过滤后,剩下多少满足查询的记录数量的比例(百分比) Extra: 执行情况的说明和描述,包含不适合在其他列中显示但是对执行计划非常重要的额外信息 MySQL5.6引入了Index Condition Pushdown(ICP)的特性,进一步优化了查询。Pushdown表示操作下放,某些情况下的条件过滤操作下放到存储引擎。 在5.6版本之后: MySQL使用了ICP来进一步优化查询,在检索的时候,把条件 customer_id>=300AND customer_id<=400也推到存储引擎层完成过滤,这样能够降低不必要的IO Extra为 Usingindex condition就表示使用了ICP优化。 ?

    40920

    mysql优化sql

    今天例行查看日志,发现有个sql在本地查询速度较快,在服务器环境下查询速度较慢,达到了6s之多。说下优化思路,原本事先将子查询优化下,后来排查下,发现是mysql缓存问题。为以后排查问题涨了点知识。 优化sql语句优化mysql配置、一、sql优化优化前SELECTspace_id,max_temp,min_temp,avg_temp,create_time FROM( SELECT space_id innodb_buffer_pool_size = 3221225472sql查询效率显著提高如果想永久修改,需要修改下mysql的配置文件,我这里就暂时不改了。 C:\ProgramData\MySQL\MySQL Server 5.7\my.ini路径图片修改my.ini搜索 innodb_buffer_pool_size注意:用记事本保存的话,要注意保存的文件的编码 必须是ANSI图片修改后,重启mysql即可。

    16940

    MySQL——SQL查询优化

    慢查询日志 slow_query_log 启动停止记录慢查询日志,默认不启动 slow_query_log_file 指定慢查询日志的存储路径以及文件,默认情况下保存在MySQL的数据目录中 long_query_time 指定记录慢查询日志SQL执行时间的阈值,默认值为10秒,通常改为0.001秒也就是1毫秒可能比较合适 log_queries_not_using_indexes 是否记录未使用索引的SQL 设置开启慢查询 global slow_query_log=on set global long_query_time=0.001 set global slow_query_log_file='/var/lib/mysql installation.html brew install percona-toolkit pt-query-digest --explain h=127.0.0.1, u=root, p=p@ssWord slow-mysql.log 实时获取存在性能问题的SQL

    26240

    Mysql学习-sql优化

    选择优化的数据类型 1)更小的通常更好:一般情况下,尽量使用可以正确存储数据的最小数据类型。 因为如果查询中包含可为NULL的列,对于Mysql来说更难优化Mysql索引 Mysql索引为什么会采用B+Tree,需要考虑以下几个问题: 对具体的数据可以快速搜索、如何快速查找区间数据、支持模糊查询、支持分页、支持排序(正序和逆序)。 对于sql优化: 1.通常如果查询中带有or的join时,可以考虑将其变成两个确切的sql进行UNION ALL,此时执行的效率比采用or要高得多。 2. 对于多个 join 可以考虑将其分解成多个sql子句,在程序中拼接,此时的效率比join的效率要高。 4. 采用sql执行计划,对查询慢的sql子句进行优化。 5. 考虑采用延迟关联。

    17210

    《收获,不止SQL优化》 - 获取执行计划的方法对比

    这是杂货铺的第450篇文章 曾经写过关于如何得到Oracle执行计划的文章,《一个执行计划异常变更的案例 - 外传之查询执行计划的几种方法》,其中介绍了各种能得到SQL执行计划的方法,梁老师的书 《收获,不止SQL优化》,对这几种方法,从获取步骤、优缺点、应用场景等方面,做了系统整理,可以比较学习, 方法 获取步骤 优点 缺点 应用场景 explain plan for 步骤1:explain 知道sql_id立即可得到执行计划,和explain plan for一样无须执行;2. 可以得到真实的执行计划; 1. 执行计划中的谓词部分不能清晰地展现出来; 如果SQL中含函数,函数中又套SQL等,即存在多层调用,想准确分析只能用该方法 awrsqrpt.sql 步骤1: @? 想观察某条SQL的多个执行计划用该方法 为了获得最准确的执行计划,最重要的一点,就是这条SQL是否真正执行过,只有真正执行过,相应的执行计划才是最真实的,否则通过预估得到的,就会存在偏差的可能, 为了方便编辑

    28730

    Spark sql逻辑执行计划优化器——EliminateOuterJoin【消除outerjoin】

    所有优化器的前提:不影响查询结果,即要保证优化前和优化后两个sql执行的效果相同 EliminateOuterJoin的主要作用是消除外连接(left,right,full),比如把left join、 EliminateOuterJoin优化器主要处理的是Filter的子节点为Join节点的情况 代码核心流程 为啥可以做这样的转化呢? 从优化器的顺序上来看: 该优化器在谓词下推优化器之前执行

    24740

    Oracle之SQL优化专题03-如何看懂SQL执行计划

    专题第一篇《Oracle之SQL优化专题01-查看SQL执行计划的方法》讲到了查看SQL执行计划的方法,并介绍了各种方法的应用场景,那么这一篇就主要介绍下如何看懂SQL执行计划。 毕竟如果SQL执行计划都看不懂,那优化就无从谈起了。 关于如何看懂SQL执行计划,我把它简单分为3个部分: 1.判断执行计划的执行顺序 2.理解执行计划每步的含义 3.了解执行计划相关的信息 1.判断执行计划的执行顺序 口诀:先子后父,先上后下。 一般简单的执行计划可以直接根据这个口诀来判断执行计划的执行顺序。类似的口诀还有"最右最上"之类,其表达的意思都是一样的,选择一种自己易接受的口诀记忆即可。 这里需要特别注意的是: 1)实际上这个所谓的口诀得到的执行顺序只是为了方便我们理解操作数据的顺序,而执行计划其实是按照Id从上往下递归调用的,简单说其实优化器首先判断是一条select语句,涉及多表关联

    29410

    MySQL- SQL执行计划 & 统计SQL执行每阶段的耗时

    ---- 某些SQL查询为什么慢 要弄清楚这个问题,需要知道MySQL处理SQL请求的过程, 我们来看下 MySQL处理SQL请求的过程 客户端将SQL请求发送给服务器 服务器检查是否在缓存中是否命中该 SQL,未命中的话进入下一步 服务器进行SQL解析、预处理,再由优化器生成对应的执行计划 根据执行计划来,调用存储引擎API来查询数据 将结果返回给客户端 ---- 查询缓存对SQL性能的影响 query_cache_type 预处理及生成执行计划 接着上一步说,查询缓存未启用,或者 未命中查询缓存 , 服务器进行SQL解析、预处理,再由优化器生成对应的执行计划MySQL会依赖这个执行计划和存储引擎进行交互 . 包括以下过程 语法解析: 包含语法等解析校验 预处理 : 检查语法是否合法等 执行计划: 上面都通过了,会生成执行计划。 ---- 造成MySQL生成错误的执行计划的原因 存储引擎提供的统计信息不准确 执行计划中的估算不等同于实际的执行计划的成本 MySQL不考虑并发的查询 MySQL有时候会基于一些特定的规则来生成执行计划

    48420

    扫码关注腾讯云开发者

    领取腾讯云代金券