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

是什么原因导致执行计划被快速从计划缓存中移除?

执行计划被快速从计划缓存中移除的原因可能有以下几点:

  1. 缓存空间不足:计划缓存是有限的,当缓存空间不足时,系统会根据一定的策略将一些执行计划从缓存中移除,以为新的执行计划腾出空间。
  2. 执行计划过期:执行计划可能会因为表结构变化、统计信息变化等原因而过期。当一个执行计划过期时,系统会将其从缓存中移除,以便重新生成一个适应当前情况的执行计划。
  3. 执行计划被主动移除:在某些情况下,开发人员或管理员可能会手动清除执行计划缓存,以解决性能问题或避免执行计划的不一致性。
  4. 服务器重启:当服务器重启时,计划缓存会被清空,所有执行计划都会被移除。
  5. 执行计划被替代:当系统发现某个执行计划的性能较差时,可能会选择替代该执行计划,将其从缓存中移除。

总结起来,执行计划被快速从计划缓存中移除的原因主要包括缓存空间不足、执行计划过期、被主动移除、服务器重启以及被替代等。

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

相关·内容

性能调优之CPU

CPU资源,大量数据加载到内存也会引起内存压力,导致计划缓存移除,使得SQL Server必须重新编译执行计划,编译和生成执行计划也是高CPU开销操作。...有些时候,针对一个查询的第一次传参,已经产生了一个执行计划,当后续传参时,由于存在对应参数的数据分布等问题,导致原有的执行计划无法高效地响应查询请求,这就出现参数嗅探问题。...“针对即席工作负载进行优化”是一个Server级别的性能优化选项,用于提高包含许多临时批处理的工作负载的计划缓存的效率,如果把该选项设置为True,则数据库引擎在首次编译批处理时只保留计划缓存的一个存根...当再次调用该批处理时,数据库引擎识别出该批处理在之前被执行过,进而计划缓存删除该执行计划的存根,并把完全编译的执行计划添加到计划缓存。...当非参数化的Ad-Hoc查询较多时,可以避免计划缓存存储过多的不会被复用的执行计划

1.2K30

参数化(一):计划缓存

第一篇我将介绍关于计划缓存的内容。为了理解参数化,有必要先理解理解执行计划如何缓存。      SQLServer保留一定数量的内存来保存执行计划缓存。...如果已经有了这个精确的执行计划,那么能节省大量的资源和时间。查询处理器如何查询批处理是否在缓存的那?当一个新的批处理产生,它的哈希值计算并且与已经在缓存执行计划比较。...例如,潜在的表和索引的架构已经在计划生成后发生了变化,或许新的列加入表,或者索引被删除…;另外一个原因统计信息过期。如果计划基于统计信息生成的,就会被标记过期(表的大量变动)。...这意味着再次进行批处理优化,然后新的执行计划生成、放置在原来无效的缓存内存。重编译已经存在的计划比编译新的要快。因为它没必有解析和简化步骤。     一般来说,你的目标是提高计划重用率。...既然内存有限,有大量的计划存储。计划缓存将增加大量数据缓存,因此更少的数据也存储在缓存,并且内存管理器将必须移除旧的计划缓存以便去有更多的空间为新的计划。      这就是参数化扮演重要的角色。

50380
  • 新人分享系列-蘑菇街主搜Dump拼装服务演化

    基于配置数据,根据不同的策略解析,最终生成一份执行计划计划指出:来自各个消息队列的消息,分别需要执行哪些接口,哪些接口的入参可以从缓存获取,每个接口的输出字段是哪些,字段的容灾策略是什么样的,等等信息...我们一共使用了4种策略进行执行计划的生成:全部为insert操作的doc级更新执行计划;不使用缓存并生成update消息的字段级更新执行计划;使用缓存并生成update消息的缓存字段级更新执行计划;不使用缓存补全指定字段的字段配置计划...执行计划在每次reload之后进行生成并存储与内存。生成多种执行计划的目的是为了减少对缓存的强依赖,避免因为缓存不稳定或缓存脏数据的问题导致拼装服务不可用。计划的选用通过开关控制。...如果因为key失效等原因导致未读取到指定字段数据,则直接通过“字段配置计划”进行指定字段的拼装。保证拼装主流程不需要关心繁琐的预处理流程。 Dump主流程:处理商品信息补全。...根据消息队列商品变更数据的来源以及执行计划配置开关,确定需要执行的执行计划,对执行计划进行商品主键填充,生成一份可执行的执行计划,并传递给预处理模块进行缓存相关的优化处理。

    1.2K140

    数据库如何解析执行SQL

    : 是否打开缓存 OFF 关闭 ;ON 总是打开 query_cache_wlock_invalidate: 如果某个数据表锁住,是否仍然从缓存返回数据,默认是OFF,表示仍然可以返回 0x03:语法分析器和查询预处理器...0x04:查询优化器 语法树认为合法之后,由优化器将其转化为执行计划。一条查询可以有很多种执行方式,最后都返回相同的结果。优化器的作用就是找到这其中最好的执行计划。...有很多种原因导致MySQL优化器选择错误的执行计划,比如: 1. 统计信息不准确。 2. 执行计划的成本估算不等同于实际的执行计划的成本。 3. MySQL的最优可能与你想的最优不一样。...字面意思可以看出,它表示优化器已经执行计划移除了该表,并以一个常数取而代之。...在根据执行计划逐步执行的过程,有大量的操作需要通过调用存储引擎实现的接口来完成,这些接口就是我们称为“handler API”的接口。

    1.4K20

    【MOS】library cache lock 等待事件 原因和解决方案 (Doc ID 2896611.1)

    原因: 共享的SQL语句过期 如果共享池太小,共享游标将从library cache移除,下次使用时需要重新加载。重新加载时需要硬解析,这会导致CPU资源消耗和锁的竞争。...如果发生硬解析的SQL语句中并没有使用常量(Literals),则可能由于 library cache 移除了本来可以共享的SQL语句。...如果发生硬解析的SQL语句中并没有使用常量(Literals),则可能由于 library cache 移除了本来可以共享的SQL语句。...风险细节: ; 改为使用绑定变量后可能会导致一些SQL语句执行计划变差,修改后的语句需要经过彻底的测试以避免性能下降。...而CURSOR_SHARING=FORCE 会导致选择不适合的执行计划

    68210

    深入解析MongoDB Plan Cache

    那这里我们归纳为2个主要问题: MongoDB生成执行计划是如何选择索引的? MongoDB决定是否采用cache执行计划的条件是什么?...在有多个执行计划可选择的时候,MongoDB会选择一个最优的执行计划存放在cache,MongoDB对同一类型的SQL(SQL基本一样,只有过滤条件具体的value不一样)会直接cache拿出执行计划...索引扫描该字段的命中数量少于B次,则最终肯定会达到IS_EOF状态,这个时候还是继续用缓存执行计划。...当然这里还有一部分原因就是本身我们的collection有5亿条记录,那这个也是放大这次故障的一个主要原因。 那这里我们是不是想到了后面只要出现这条SQL就会导致慢查最终导致故障?...是的,确实是会导致慢查,但是不一定会导致故障,因为早在2017年的时候该SQL就出现了好几次。但是最终都自己恢复了,我们来看看是什么原因

    76540

    夜维执行慢的原因探究

    这里实际还有个问题,运行DBA的同事从缓存幸运的找到了慢SQL的SQLID,查看他的执行计划是“索引2”的INDEX FULL SCAN,虽然这样的结果和3的结果有些出入,但都可以一定程度说明索引选择的不正确是造成...之所以SQLID找到的执行计划和F5得到的执行计划不同,根本原因是F5得到的执行计划实际是封装了EXPLAIN PLAN命令,其未真正执行这条SQL,而SQLID是真正执行的SQL在缓存的ID,因此是真正执行了的...,通过SQLID查找对应的执行计划,以确定最优的执行计划是什么,如果确定是“索引1”,可以使用HINT强制SQL使用“索引1”,只是这张表的数据量并不会有一个显著的变化,因此才可以将HINT作为一种方法...,使用HINT的副作用,就是无论环境有何变化,都会使用HINT明确的索引,一旦环境的变化导致最优执行计划有变,那么HINT就比较危险了,而且HINT是需要程序修改的,因此这种方法是下下策。...要明白INDEX SKIP SCAN的适用条件,不是什么时候带有INDEX的执行计划都是最好的,需要看场景。 3.

    58130

    深入解析MongoDB Plan Cache

    那这里我们归纳为2个主要问题: MongoDB生成执行计划是如何选择索引的? MongoDB决定是否采用cache执行计划的条件是什么?...在有多个执行计划可选择的时候,MongoDB会选择一个最优的执行计划存放在cache,MongoDB对同一类型的SQL(SQL基本一样,只有过滤条件具体的value不一样)会直接cache拿出执行计划...索引扫描该字段的命中数量少于B次,则最终肯定会达到IS_EOF状态,这个时候还是继续用缓存执行计划。...当然这里还有一部分原因就是本身我们的collection有5亿条记录,那这个也是放大这次故障的一个主要原因。 那这里我们是不是想到了后面只要出现这条SQL就会导致慢查最终导致故障?...是的,确实是会导致慢查,但是不一定会导致故障,因为早在2017年的时候该SQL就出现了好几次。但是最终都自己恢复了,我们来看看是什么原因

    83420

    Mysql

    服务器先会检查查询缓存,如果命中了缓存,则立即返回存储在缓存的结果。否则进入下一阶段; 3. 服务器端进行SQL解析、预处理,再由优化器生成对应的执行计划; 4....查询优化器 现在语法树认为合法的了,并且由优化器将其转化为执行计划。一条查询可以由很多种执行方式,最后都返回相同的结果。优化器的作用就是找到这其中最好的执行计划。...有很多种原因导致MySQL优化器选择错误的执行计划,比如: 1. 统计信息不准确。 2. 执行计划的成本估算不等同于实际的执行计划的成本。 3. MySQL的最优可能与你想的最优不一样。 4....字面意思可以看出,它表示优化器已经执行计划移除了该表,并以一个常数取而代之。...如果查询可以缓存,那么MySQL在这个阶段,会将结果存放到查询缓存。 MySQL将结果返回客户端是一个增量、逐步返回的过程。

    71910

    SQL执行计划及优化策略

    **访问路径(Access Paths)**:描述如何获取数据,比如全表扫描或索引扫描,以及索引的选择和使用情况。 5....理解并合理解读SQL执行计划对于SQL性能调优至关重要,可以帮助我们定位慢查询的原因,针对性地调整索引、改写SQL语句或者调整数据库参数,从而提高系统的整体性能。 优化SQL执行策略 1....**索引优化**: - 分析执行计划是否存在全表扫描,如果某个表在不需要大量数据的情况下进行了全表扫描,考虑是否能添加合适的索引来避免这种情况。...索引可以帮助快速定位所需数据,减少不必要的读取。 - 检查现有索引是否有效利用,有时由于谓词条件、连接条件或排序方式与索引不匹配,可能导致索引未被选择。必要时创建覆盖索引或重新设计索引。...**应用层优化**: - 尽量减少应用程序的多次相同查询,使用批处理或存储过程集中处理。 - 对于频繁执行的复杂查询,考虑将其结果缓存起来,避免频繁计算。

    23210

    一条查询sql的完整执行流程(连接到引擎,穿插涉及到的知识,超详细)

    所以缓存这一块,我们还是交给ORM框架(比如MyBatis默认开启了一级缓存), 或者独立的缓存服务,比如Redis来处理更合适。 而且,MySQL 8.0缓存已经移除了!!!!!!!!!...语法解析和预处理 没有使用缓存的话,就会跳过缓存的模块,下一步要做什么呢? 我们先想一下,为什么一条SQL语句能够识别呢?...然后记录位置,每个符号是什么类型,哪里开始到哪里结束。...问题又来了: 1、逻辑的角度来说,我们的数据是放在哪里的,或者说放在一个什么结构里面? 2、执行计划在哪里执行?是谁去执行?...将所有数据存储在RAM,以便在需要快速查找非关键数据的环境快速访问。这 个引擎以前被称为堆引擎。

    1K20

    百度高级Java面试真题

    确保静态集合的对象在不再需要时移除。...请解释MySQL的执行计划以及如何根据它进行查询优化。 MySQL的执行计划是数据库在执行SQL查询前对如何访问数据所做的一系列优化选择。...通过对执行计划的分析和理解,你可以对查询进行优化,改进其性能。然而,需要注意的是,查询优化是一个迭代过程,可能需要多次调整和测试。 MySQL的索引覆盖扫描是什么,如何使用它提高查询效率?...检查执行计划:使用EXPLAIN关键字来检查查询的执行计划,确保Extra列中出现"Using index"。这表明查询正在使用索引覆盖扫描。...提高缓存效率:索引条目通常比数据行小,因此更多的索引条目可以缓存在内存,从而提高缓存命中率。 需要注意的是,并不是所有的索引都适合用于索引覆盖扫描。

    13410

    参数化(四):处理非均匀数据分布

    这个计划放在缓存便于重用。当其他用户执行查询closed状态的时候,相同的执行计划重用,这就很可能是一个灾难,因为现在将进行8M个键值查找操作。    ...那么现在我们发现了问题,接下来让我们看一下可能的解决方案… Solution #1 – sys.sp_recompile     很简单就是使用系统存储过程sys.sp_recompile从缓存移除指定的执行计划或者所有计划引用的指定表和视图...整个例子运行时执行这个语句时,暂停执行,重新编译该查询,生成新的执行计划。而其他部分则使用计划缓存。运行时编译带来的好处就是使优化器能预先知道所有的运行时值,甚至不需要参数嗅探。...每个计划编译一次,然后从这点来说每个执行都会得到最佳计划,因为计划基于参数值产生,所以合理的分组导致生成对应组的计划。     听起来像魔法吗?...一旦第一次被执行以后,计划生产在缓存。多亏了参数嗅探,从此以后,只要普通国家的存储过程被执行都会使用这个计划

    91680

    BAT 必问的 MySQL 面试题你都会吗?

    1、MySQL 的 latin1 是什么字符集? 这个字符集相信大家都见过,一般在创建数据库的时候会进行设置。它在 Java 中代表的就是 ISO-8859-1。...因为,连接器是负责处理管理连接,权限验证的;分析器是进行词法分析,语法分析的;优化器是进行语句优化,生成执行计划,选择索引的;执行器是真正执行 SQL 语句的,并返回结果集的。...4、MySQL 5.8 为什么把查询缓存这一块移除了? 这个查询缓存,这一块估计很多人都没注意到。新版本的 5.8 版本的 MySQL 数据库已经移除了查询缓存这一块的设计。...而且在 5.7 版本也不推荐使用了。移除原因是,虽然查询缓存有时候能比较快的返回数据,但是维护起来太麻烦了。而且缓存命中率太低了。...比如,select now() 就不能缓存,再比如,select version() 就没必要缓存。综合考虑,MySQL 把它给移除了。 更多关于 MySQL 的面试题,参考我的面试题小程序。

    58520

    MySQL 查询执行的过程

    查询的生命周期大致可以按照顺序来看:客户端到服务端,然后在服务器上进行解析,生成执行计划,执行,并返回结果给客户端。...四、查询优化器 ---- 当语法树认为合法时,优化器会将其转化成执行计划。一条查询可以有很多种执行方式,最后都返回相同结果。优化器的作用就是找到这其中最好的执行计划。...很多原因导致 MySQL 优化器选择错误的执行计划,如下: 【1】统计信息不准确:MySQL 依赖存储引擎提供的统计信息来评估成本,但有的偏差可能非常大。...【2】执行计划的成本估算不等同实际执行的成本:所以即使统计信息精准,优化器给出的执行计划也可能不是最优的。例如某个执行计划虽然需要读取更多的页面,但是它的成本却更小。...如果查询可以缓存,那么 MySQL 在这个阶段也会将结果存放到查询缓存。MySQL 将结果集返回客户端是一个增量、逐步返回的过程。

    2.2K30

    深入解析:由SQL解析失败看开发与DBA的性能之争

    是什么原因导致这么多的解析失败呢?另外解析失败的 SQL 是否会导致大量 latch 竞争?解析失败的 SQL 是否会在共享池中存储?怎么查询到解析失败的 SQL?...Library cache 是 shared pool 的一块内存区域,主要作用就是缓存执行过的 SQL 语句所对应的执行计划信息等信息。...,如果找到了就直接用该 sql 缓存执行计划等,如果找不到则从头解析,并把解析后执行计划缓存在 hash bucket 。...父游标与子游标结构是一样的,区别在于 sql 文本存储在父游标对应的对象句柄,而 sql 的执行计划等信息存储在子游标对应的库缓存对象句柄 heap 6 。...找下该 SQL 子游标的信息: 子游标 heap 6 的地址为 000000007625FBF8 句柄存储的也就是执行计划相关的信息。

    1.6K50

    一条SQL如何MySQL架构的各个组件操作执行的?

    查询缓存在MySQL 8.0已被移除,不详细解释。 分析器: 解析查询语句,检查语法。 验证表名和列名的正确性。 生成查询树。...优化器:分析查询树,考虑各种执行计划,估算不同执行计划的成本,选择最佳的执行计划。在这个例子,优化器可能会选择使用name索引进行查询,因为name是索引列。...在查询执行过程,执行器需要根据优化器选择的执行计划存储引擎获取指定表的数据。 (2)ON:ON子句用于指定连接条件,它通常与JOIN子句一起使用。...在查询执行过程,执行器会根据优化器选择的执行计划存储引擎获取需要连接的表的数据。然后,执行器根据JOIN子句的类型和ON子句中的连接条件,对数据进行连接操作。...查询1在连接操作后应用过滤条件,这可能导致右表为NULL的关联记录因为右表的过滤条件而排除在外。

    93230

    【重磅推荐】Library Cache等待事件深入剖析SQL解析

    是什么原因导致这么多的解析失败呢?另外解析失败的 SQL 是否会导致大量 latch 竞争?解析失败的 SQL 是否会在共享池中存储?怎么查询到解析失败的 SQL?...Library cache 是 shared pool 的一块内存区域,主要作用就是缓存执行过的 SQL 语句所对应的执行计划信息等信息。...当 sql 执行时候,首先会对 sql 文本进行 hash 运算然后根据 hash 值去相关 hash bucket 遍历,如果找到了就直接用该 sql 缓存执行计划等,如果找不到则从头解析,并把解析后执行计划缓存在...父游标与子游标结构是一样的,区别在于 sql 文本存储在父游标对应的对象句柄,而 sql 的执行计划等信息存储在子游标对应的库缓存对象句柄 heap 6 。...可以看到是没有子游标产生的,因为该 SQL 执行错误不会有执行计划相关信息出现。 ? x$kglob 也可以查到 kglobhd0 kglobhd6 都为空。

    1.1K40

    【数据库设计和SQL基础语法】--连接与联接--联接的优化与性能问题

    高延迟可能会对应用程序的性能产生负面影响,特别是在需要快速响应用户请求的在线系统。 资源消耗增加: 联接大表可能导致数据库引擎需要更多的内存和计算资源来执行查询。...频繁的网络通信可能成为性能瓶颈,特别是在分布式数据库环境缓存效果下降: 大表的联接可能导致缓存效果下降,因为大部分数据无法完全存储在内存。...数据库引擎可能需要频繁地磁盘读取数据,而不是内存获取,导致性能下降。...为了优化索引,可以采取以下策略: 分析查询执行计划: 使用数据库性能分析工具分析查询执行计划,以确定哪些索引使用,哪些未被使用。 根据执行计划进行调整,确保优化索引的使用。...使用数据库分析工具: 使用数据库性能分析工具分析查询执行计划,了解哪些索引使用,哪些未被使用。 根据执行计划进行索引调整,确保优化索引的使用。

    20610
    领券