首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

从构建执行计划的角度来看,"select*"有什么影响?

从构建执行计划的角度来看,执行"select*"语句可能会导致以下影响:

  1. 执行计划不稳定:在MySQL中,"select *"语句可能会导致不同的执行计划,这取决于查询的表结构、索引、查询条件等因素。因此,执行计划可能会频繁变化,导致应用程序的性能不稳定。
  2. 资源消耗高:"select *"语句可能会导致MySQL服务器处理大量数据,从而可能导致资源消耗较高,如CPU、内存和磁盘空间等。
  3. 查询性能差:由于"select *"语句可能会导致执行计划不稳定和资源消耗高,因此查询性能可能较差。

因此,在构建执行计划时,应该尽量避免使用"select *"语句,而是根据查询条件有选择地查询必要的列,以优化查询性能和资源消耗。

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

从操作系统的角度来看,什么是线程与进程

我们平常说的进程和线程更多的是基于编程语言的角度来说的,那么你真的了解什么是线程和进程吗?那么我们就从操作系统的角度来了解一下什么是进程和线程。...在给出了错误参数时,面向屏幕的交互式进程通常并不会直接退出,因为这从用户的角度来说并不合理,用户需要知道发生了什么并想要进行重试,所以这时候应用程序通常会弹出一个对话框告知用户发生了系统错误,是需要重试还是退出...如果我们能够正确的操作,使两个不同进程不可能同时处于临界区,就能避免竞争条件,这也是从操作系统设计角度来进行的。 尽管上面这种设计避免了竞争条件,但是不能确保并发线程同时访问共享数据的正确性和高效性。...21.jpg 从抽象的角度来看,我们通常希望进程的行为如上图所示,在 t1 时刻,进程 A 进入临界区,在 t2 的时刻,进程 B 尝试进入临界区,因为此时进程 A 正在处于临界区中,所以进程 B 会阻塞直到...通过使用这些过程,用户线程完全可以实现在用户空间中的同步,这个过程仅仅需要少量的同步。 我们上面描述的互斥量其实是一套调用框架中的指令。从软件角度来说,总是需要更多的特性和同步原语。

1.7K20

MySQL中的SQL优化建议那么多,该如何有的放矢

所以从这个角度来看,我们不妨按照毫秒级优化的标准来看,这条SQL需要做哪些补充的工作。...,涉及到两个结果集的合并,如果返回结果较多,可能是瓶颈 从执行结果来看,让我有些意外,其中virtual_order的返回结果竟然有40多万行,相当于直接走了全表扫描。...而其他的部分也会收到相关影响,所以后续的处理都会受到影响。 为了快速定位问题,我把两个子查询拆开单独执行,查看执行计划,这是分析瓶颈最快的一种处理思路。...,得到的执行计划列表如下: 执行计划列 Where条件: name=20 where条件: name='20' id: 1 1 select_type: SIMPLE SIMPLE partitions...,就都规规矩矩了,这样我们就解决了瓶颈问题,而那些规范,更好的改进就可以逐步展开了,而从建议的角度来看,采用的概率也会高一些。

69031
  • 再来一个诊断SparkSql慢任务的案例吧

    每次找问题的过程很简单,但是其实其中是有很多基本功在里面的,比如这次优化用到的基本功: sparksql的执行计划得熟悉,至少得能看懂啥是啥 sparksql的Join选择策略,5大Join实现类的基本原理...4、看stage的Summary Metrics页面,从已完成的task来看,task平均的运行情况,判断有没有数据倾斜、是不是所有task都处理了太多的数据量、有没有慢节点的机器等 5、研究这段sql...上下文的数据,确认数据层面有没有数据倾斜、大字段啊这些 上面这些,是从数据开发的角度来看,有没有改进的地方,如果从sql的角度确实看不出问题,我们需要一些推断,比如: 每个task处理的数据量不大,并且没有复杂的计算逻辑...2、找sql的dag图,再确定一下出卡点的任务对应的是哪一块的执行计划,输入和输出的上下文是什么 如上,最终找到和卡点task对应的dag图,是BroadcastHashJoin,左表是一个经过一系列计算后输出的中间结果...但是,我们看执行计划,右表走广播了呀,这时,就基本确定了是sparksql生成的执行计划有问题。

    80650

    如何使用calcite rule做SQL重写(上)

    对于 rewrite sql 这个需求,大家都会有各自得需求,从我的角度来看,主要分为: 对象改写 简单的例如对Sql对象的替换 select a.firstname || a.lastname from...在这里可能伴随着Sql语句得优化,也可能是对执行计划的优化。 下面我们以SQL优化为例,来看看calcite如何做。...同时,在 RBO 中 SQL 写法的不同很有可能影响最终的执行计划,从而影响执行计划的性能。...从上述描述可知,CBO 是优于 RBO 的,原因是 RBO 是一种只认规则,对数据不敏感的呆板的优化器,而在实际过程中,数据往往是有变化的,通过 RBO 生成的执行计划很有可能不是最优的。...事实上目前各大数据库和大数据计算引擎都倾向于使用 CBO,但是对于流式计算引擎来说,使用 CBO 还是有很大难度的,因为并不能提前预知数据量等信息,这会极大地影响优化效果,CBO 主要还是应用在离线的场景

    1.7K21

    第 47 期:EXPLAIN TYPE 列的 JOIN 常见场景详解(上)

    本专栏语言通俗易懂,选取大量示例为您详细说明个中奥妙~ 面向的对象: DBA 数据库开发者 第 47 期正文 专栏连载至此,相信读者们已经对一条 SQL 的优化步骤、执行计划等有了一个大概的了解。...因为从 MySQL 优化器的角度来看,所有 SQL 都是 JOIN 查询(单表检索可以看成过滤字段和主键做 JOIN 的特殊类型)。由于内容较多,文章分成了上下两部分,接下来是上部的正文。...这种场景从 SQL 角度来讲,应该避免掉;如果实在无法避免,可以想办法减少两表 JOIN 的记录数。...rows: 93 filtered: 100.00 Extra: NULL 1 row in set, 1 warning (0.00 sec) 其实这点从传统的执行计划结果里看不出什么效果...;更进一步,如果从索引角度来讲,就是全表扫了。

    7300

    什么时候 MySQL 查询会变慢?

    前面几篇文章和小伙伴们聊的基本上都是从索引的角度去优化 MySQL 查询,然而,索引创建的好,并不意味着查询就一定快,影响查询效率的因素特别多,今天我们就来聊一聊这些可能影响到查询的因素。 1....我们来看如下一张图: 首先,用户通过连接器和服务端之间建立通信连接,这个说白了就是一个 Socket 通信,用户名/密码的校验,用户权限的判断等等,都是在这个连接器中完成的。...最后就是执行器了,执行器调用搜索引擎提供的具体接口去获取数据。 这张图大家大概有个印象,在后续的 MySQL 查询和优化中,很多东西就容易理解了。 接下来我们就来看看什么情况下查询会变慢。 2....,这么写也看不出来性能明显的差异,但是当列数和数据量大了,那么 select * 带来的影响就会比较大了。...关注扫描行数 在查询的时候,我们可以通过 explain 来查看执行计划,执行计划中有一个指标是扫描行数,如下图中的 rows,这个就表示查询优化器预估要扫描多少行记录,filtered 则表示预估满足条件的比例

    17820

    生产环境sql语句调优实战第十篇(r3笔记第39天)

    陆陆续续写了九篇关于生产环境sql语句的调优案例,发现了不少问题,可能有些问题回头来看是比较低级的错误,稍加改动就能够运行在秒级,有些可能是在秒级到毫秒级的小步提升等等,不管调优的改进多大,从dba的角度来看...如果有时候从业务角度来下下功夫,可能某种程度上效果要更好于基于资源/代价的调优。 最近客户反馈有几条sql语句IO消耗很高,希望我们能够给提点建议。 sql语句很短,但是运行时间在9秒左右。...SUB_STATUS"='A') 4 - access("SUBSCRIBER_NO"="SUBSCRIBER_NO") 5 - filter("PRODUCT_STATUS"='A') 如果从资源代价的角度来看...看着sql语句比较简单,但是还没有立竿见影的效果也有些让人着急。数据库的角度的一些调整可能奏效不大,自己就想看看从业务角度能做点什么。 静下心来看看sql语句。...,这样一个号码为什么没有加入索引,从业务的角度来琢磨,可能是有做号码变更之类的操作的时候这个号码就会变化比较频繁。

    91850

    POSTGRESQL V12 Perpare 功能到底是个什么?

    POSTGRESQL 的 prepare 的功能是什么, 有什么用,为什么在MYSQL上不曾听说有这样的功能。那么今天就需要好好的说一说POSTGRESQL 的prepare的功能。...首先我们要知道他们的不同点在哪里,有一句话表达普通的语句执行时静态的,需要进行执行计划的筛选执行起来相对较慢的并且容易受到攻击的一种语句的执行的方式。...而PERPARE的方式是动态的并且由于可以不在进行执行计划的选择,用相对较快的执行的速度,并且可以从某种角度上避免攻击的一种语句执行的方式。...下面我们通过一个练习来看看PREPARE是如何使用的 1 我们创建一个数据库 prepare create database prepare 2 然后我们创建一个表其中灌入数据100万的同样的数据...,反而降低你的查询速度 2 在某些情况下会无法使用PREPARE的方式 ,例如你使用了中间件的方式并且中间件的方式中通过transaction的方式来进行变换你的查询复用,可能这样的prepare的方式的优势会被影响

    42230

    MySQL 5.5迁移到5.7的性能问题排查案例

    问题的背景是有一个业务的数据库从MySQL 5.5迁移到了MySQL 5.7,原来在5.5中有一个SQL秒级就能完成,但是在5.7版本中执行时间长了好多,业务也产生了延迟。...按道理5.7的功能和改进更多,比5.5要更稳定,出现这样的问题,其实是比较奇怪的,从我们的初步理解来看,方向应该是优化器参数的影响。...然后我们扩大了影响范围,是不是有其他我们不知道的优化器参数导致的呢。我们调整了思路。...应用那边也开始催促,一旦影响到业务,最差的情况就是需要把已有的5.7环境降级到5.5, 这显然不是我们彼此希望的,从技术可控的角度来说,我们可以确定下思路。 1....3.从问题的本质来说,就是希望SQL执行效率提高,如果从SQL的角度进行调整,对已有的SQL实现做改动,能够重写SQL,哪怕这道坎需要和业务方反复确认,只要目标明确,也是值得的。

    1.1K20

    第 49 期:根据 EXPLAIN EXTRA 栏提示进行优化(一)

    常见场景详解(下) 经过前面篇幅的持续阅读,相信大家对 MySQL 的执行计划已经有了一个较为深入的理解。...对于 MySQL 来讲,默认的 EXPLAIN 结果里有一个 Extra 栏,其信息是 MySQL 对指定 SQL 执行计划的一些更加易读的数据,类似于提示信息。比如,是否用到临时表?是否用到排序?...所以单从数据库角度来讲,很多公司里定制的开发规范都强调在写 SQL 时,只需拿必要字段而不推荐写 SELECT * 也是很有道理的。...如果单从执行效率角度来讲,升序和倒序的方式其实没有什么大的差别,仅仅是索引数据存储的方式不同。...r2=1, 从优化器角度来看,不需要访问实体表即可拿出结果。

    3500

    一条SQL引发的“血案”:与SQL优化相关的4个案例

    下面来看看执行计划,如图1-1所示。 执行计划触目惊心,优化器评估返回的数据量为3505T条记录,计划返回量127P字节,总成本9890G,返回时间999:59:59。 ?...▲图1-1 执行计划 分析结论 从执行计划中可见,两表关联使用了笛卡儿积的关联方式。我们知道笛卡儿连接是指两表没有任何条件限制的连接查询。...给我们的启示 从案例本身来讲并没有什么特别之处,不过是开发人员疏忽导致了一条质量很差的SQL。但从更深层次来讲,这个案例可以给我们带来如下启示。...3)限流/资源控制 有些数据库提供了丰富的资源限制功能,可以从多个维度限制会话对资源(CPU、MEMORY、IO)的使用,可避免发生单个会话影响整个数据库的运行状态。...而往往较差的执行计划发生在月底几天,且由于月底大批作业的影响,整体性能比较饱和,更突显了这个问题。

    61720

    【云和恩墨大讲堂】Oracle线上嘉年华第二讲

    我们看到这两个等待事件已经占了整体DB time的72%,大家看到这个问题,可能一般都会想到解析, 我们从以下几个角度分析: TopSQL的解析、执行频率是否合理: 故障点的library lock相关的...SQL来看,基本占据db time、parse阈值高的Top SQL解析、执行频率并没有数量级的增加,他们更像是受害者。...这样看来,这个问题是很棘手的,硬解析次数很高,但我们找不到对应的SQL在哪里。 我们接着分析,来看AWR报告里面的time model statistic ?...我们看到红色标记的部分,解析时间消耗了63.74%、解析失败消耗了50.55%。 解析失败是什么?...而跟研发沟通发现实际上union all的下层查询可以去掉,去掉后则该SQL无需改写rownum就可以直接推进到主查询中,从这个例子可以看到不严谨的代码容易造成性能隐患,影响优化器评估最合理的执行计划。

    86361

    数据库优化 – SQL优化

    大家好,又见面了,我是你们的朋友全栈君。 前面一篇文章从实例的角度进行数据库优化,通过配置一些参数让数据库性能达到最优。但是一些“不好”的SQL也会导致数据库查询变慢,影响业务流程。...本文从SQL角度进行数据库优化,提升SQL运行效率。...(感兴趣的可以翻看我之前的文章) SQL语句表象 冗长 执行时间过长 从全表扫描获取数据 执行计划中的rows、cost很大 冗长的SQL都好理解,一段SQL太长阅读性肯定会差...更进一步判断SQL问题就得从执行计划入手,如下所示: 执行计划告诉我们本次查询走了全表扫描Type=ALL,rows很大(9950400)基本可以判断这是一段”有味道”的SQL。...我们以MYSQL为例,看看执行计划是什么。

    3.6K10

    Oracle优化05-执行计划

    ---- 当CBO无法准确的获取到Cardinality时,将会发生什么? 在执行计划中, card 就是Cardinality的缩写,它表示CBO估算当前操作预期获取的记录数。...下面演示下当CBO无法准确的获取到Cardinality时,将会发生什么?...*/ id from t2 where name = 'XGJ'); ID NAME ------ ---------- 同样的 我们来看下执行计划: ?...---- 从这个试验中我们可以得到如下结论: 子查询的Cardinality的值,直接影响了主查询的执行计划,如果CBO对子查询的Cardinality判断有误,那么饿主查询的执行计划很有可能是错误的...生成SQL的执行计划时Oracle在对SQL做硬分析时的一个非常重要的步骤,它制定出一个方案告诉Oracle在执行这条SQL时以什么样的方式访问数据: 索引扫描? 全表扫描?

    79010

    一条SQL引发的“血案”:

    下面来看看执行计划,如图1-1所示。 执行计划触目惊心,优化器评估返回的数据量为3505T条记录,计划返回量127P字节,总成本9890G,返回时间999:59:59。 ?...▲图1-1 执行计划 分析结论 从执行计划中可见,两表关联使用了笛卡儿积的关联方式。我们知道笛卡儿连接是指两表没有任何条件限制的连接查询。...给我们的启示 从案例本身来讲并没有什么特别之处,不过是开发人员疏忽导致了一条质量很差的SQL。但从更深层次来讲,这个案例可以给我们带来如下启示。...3)限流/资源控制 有些数据库提供了丰富的资源限制功能,可以从多个维度限制会话对资源(CPU、MEMORY、IO)的使用,可避免发生单个会话影响整个数据库的运行状态。...而往往较差的执行计划发生在月底几天,且由于月底大批作业的影响,整体性能比较饱和,更突显了这个问题。

    68720

    Hive企业级性能优化(好文建议收藏)

    如Oracle数据库,它有多种类型的执行计划,通过多种执行计划的配合使用,可以看到根据统计信息推演的执行计划,即Oracle推断出来的未真正运行的执行计划;能够观察到从数据读取到最终呈现的主要过程和中间的量化数据...Hive中也有执行计划,但是Hive的执行计划都是预测的,这点不像Oracle和SQL Server有真实的计划,可以看到每个阶段的处理数据、消耗的资源和处理的时间等量化数据。...Hive提供的执行计划目前可以查看的信息有以下几种: 查看执行计划的基本信息,即explain; 查看执行计划的扩展信息,即explain extended; 查看SQL数据输入依赖的信息,即explain...下面将从多个完全不同的角度来介绍Hive优化的多样性,我们先来一起感受下。 1....数据格式优化 Hive提供了多种数据存储组织格式,不同格式对程序的运行效率也会有极大的影响。 Hive提供的格式有TEXT、SequenceFile、RCFile、ORC和Parquet等。

    1K10

    数据库优化 - SQL优化

    是时候 关注 我们一波了 前面一篇文章从实例的角度进行数据库优化,通过配置一些参数让数据库性能达到最优。但是一些“不好”的SQL也会导致数据库查询变慢,影响业务流程。...本文从SQL角度进行数据库优化,提升SQL运行效率。...SQL语句表象 冗长 执行时间过长 从全表扫描获取数据 执行计划中的rows、cost很大 冗长的SQL都好理解,一段SQL太长阅读性肯定会差,而且出现问题的频率肯定会更高。...更进一步判断SQL问题就得从执行计划入手,如下所示: ? 执行计划告诉我们本次查询走了全表扫描Type=ALL,rows很大(9950400)基本可以判断这是一段"有味道"的SQL。...我们以MYSQL为例,看看执行计划是什么。(每个数据库的执行计划都不一样,需要自行了解) explain sql ?

    1.7K20

    MySQL进阶突击系列(07) 如何分析优化慢SQL | 怎么看执行计划?

    当我们降服全能自恋,从孤独的想象世界进入关系的现实世界,你会发现这个世界充满爱、热情、和创造力。你会爱上这个世界,也会爱上自己。...-范围查询 3.3.6 all-全表扫描 四、SQL如何优化 一、前言背景 在日常研发工作当中,系统性能优化,从大的方面来看主要涉及基础平台优化、业务系统性能优化、数据库优化。...当业务数据量达到一定规模后,SQL执行效率可能就会出现瓶颈,影响系统业务响应。...三、如何看懂执行计划 我们拿一个执行计划出来看一下。比如: 里面有id、select_type、table、type、key、ref等字段。每个都有它特定意义。...一个复杂的SQL,里面有很多联合查询、子查询。具体哪个先执行,这里就可以通过id来看到查询优化器指定的顺序。 比如上图,id值有【1、1、1、2】。这个执行顺序是2,然后是1。

    7320

    MySQL8.0 优化器介绍(一)

    查询优化器的作用: 当我们将查询提交给MySQL执行时,大多数的查询都不像 select * from single_table;那样简单,从单个表读取所有数据就行了,不需要用到高级的检索方式来返回数据...HeadOfState`, 135 AS `Capital`, 'AU' AS `Code2`, city.* FROM world.city WHERE CountryCode = 'AUS'; 从性能的角度来看...MySQL8.0 的优化器可以讯问InnoDB是否查询所需的记录可以在缓冲池中找到,或者是否 必须从从磁盘上读取记录。这对执行计划的改进,有巨大的帮助。...最佳联接顺序 有两个个因素影响,表自身的大小,经过过滤器后每个表减少的行数。...这就是为什么索引和直方图对于获得良好的查询计划非常重要。在确定查询计划的最后,会对单个部分和整个查询进行成本估算。这些信息有助于了解优化器到达查询执行计划。

    24920
    领券