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

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

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

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

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

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

相关·内容

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

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

1.4K20

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

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

64231

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

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

50950

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

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

88721

什么时候 MySQL 查询会变慢?

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

15120

生产环境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语句。...,这样一个号码为什么没有加入索引,从业务角度来琢磨,可能是做号码变更之类操作时候这个号码就会变化比较频繁。

90150

POSTGRESQL V12 Perpare 功能到底是个什么

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

37030

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,哪怕这道坎需要和业务方反复确认,只要目标明确,也是值得

1K20

数据库优化 – SQL优化

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

3.5K10

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时以什么方式访问数据: 索引扫描? 全表扫描?

73510

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

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

58220

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

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

82261

一条SQL引发“血案”:

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

66920

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

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

90410

数据库优化 - SQL优化

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

1.6K20

【云和恩墨大讲堂】执行计划洞察ORACLE优化器“小聪明”

1唯一性字段对执行计划影响 由于在模型分析时,我们发现DEPT表DEPTNO字段是唯一。...现在来看看LEFT JOIN和INNER JOIN不同结果: ? ? 也就是说,LEFT JOIN和INNER JOIN还是差异,那么在什么情况下才能在执行计划中将DEPT“枪毙”掉呢?...即子查询D对整个SQL返回结果是没有任何影响,该SQL完全等价于如下SQL: SELECT COUNT(1) FROM EMP E 而事实上呢,我们看看ORACLE执行计划: ?...我再来看看谓词: ? 很明显,在实际执行过程中,DEPTNO是被TO_NUMBER函数包了一层,自然就走不了索引。那么是什么让ORACLE如此“昏庸”,以致“无事生非”添加一个函数呢?...会不会去查资料,研究SOME作用和用法?或许大半天后,你仍然被SOME\ANY\ALL弄得云山雾罩。 现在,我们试着执行计划去探究>SOME含义。 ?

97431

MySQL8.0 优化器介绍(一)

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

18820

MySQL8.0 优化器介绍(一)

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

26620

隐式转换案例,来挖掘开发人员技能提升

使用索引唯一扫描就能证明这点,复合索引三个字段都用上了, SQL> select * from t_001 where id = 1 and a_ts  = to_date('2020-02-...,其他字段只能作为过滤条件,使用索引范围扫描就能证明这个推测, SQL> select * from t_001 where id = 1 and a_ts  = to_timestamp('2020...对这个问题,如果各位什么其他见解,欢迎在文末留言,我们一同探讨。...当你要确定自己写SQL代码在性能上是否存在隐患时候,就可能会用到执行计划,你要知道怎么得到真实执行计划,判断执行计划正确,根据执行计划纠正自己SQL。...当你要对表结构做调整,例如增加字段、删除字段,你可能需要了解在执行过程中他会持有什么级别的锁,知道这个操作对数据库什么影响

33320
领券