SQL中键集游标选择执行计划的方式和影响因素

上次我们在《游标脚本性能问题解决与分析》讨论过动态游标的执行计划如何选择并且介绍了几种游标的基本知识。本文我们接着研究键集游标选择执行计划的方式和影响因素。

这这里我们通过一个简单的实验来对比测试并且说明结果。

准备如下测试环境:

CREATE TABLE [dbo].[test_cursor](

[number] [int] IDENTITY(1,1) NOT NULL,

[">name] [varchar](500) NULL,

[xtype] [varchar](500) NULL,

[type] [varchar](500) NULL,

[parent_obj] [varchar](500) NULL,

[crdate] [datetime] NULL,

[id] [varchar](500) NULL,

[sysstat] [int] NULL,

CONSTRAINT [PK_test_cursor] PRIMARY KEY CLUSTERED

(

[number] ASC

)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]

) ON [PRIMARY]

反复运行下面的Insert语句15次以构造测试数据:

insert into test_cursor (name,xtype,type, parent_obj,crdate,id,sysstat) select name,xtype,type, parent_obj,crdate,id,sysstat from AdventureWorks.dbo.sysobjects.

然后,为该表创建如下索引,

create index i_test_cursor_1 on test_cursor (id, crdate) include (number, name,xtype,type,parent_obj,sysstat)

create index i_test_cursor_2 on test_cursor(id,crdate)

执行以下Select语句,我们能得到下面的执行计划和统计信息:

SELECT * FROM test_cursor WHERE id>'92' ORDER BY crdate  --index seek on i_test_cursor_1

Table 'test_cursor'. Scan count 1, logical reads 17, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Rows                    Executes             StmtText

-------------------- -------------------- ---------------------------------------------------------------------------------------------------------------------------------------

992                      1                        SELECT * FROM [test_cursor] WHERE [id]>@1      ORDER BY [crdate] ASC

992                      1                        |--Sort(ORDER BY:([aa].[dbo].[test_cursor].[crdate] ASC))

992                      1                        |--Index Seek(OBJECT:([aa].[dbo].[test_cursor].[i_test_cursor_1]), SEEK:([aa].[dbo].[test_cursor].[id] > '92')

SELECT * FROM test_cursor WHERE id>'92' ORDER BY number -index seek on i_test_cursor_1

Table 'test_cursor'. Scan count 1, logical reads 17, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Rows                    Executes              StmtText

-------------------- -------------------- ---------------------------------------------------------------------------------------------------------------------------------------

992                     1                          SELECT * FROM [test_cursor] WHERE [id]>@1 ORDER BY [number] ASC

992                     1                          |--Sort(ORDER BY:([aa].[dbo].[test_cursor].[number] ASC))

992                     1                          |--Index Seek(OBJECT:([aa].[dbo].[test_cursor].[i_test_cursor_1]), SEEK:([aa].[dbo].[test_cursor].[id] > '92') ORDERED FORWARD)

以上两个ad-hoc的语句都是使用了我们创建的index  test_cursor迅速的定位和返回相应的行。

时间: 2024-09-30 21:34:58

SQL中键集游标选择执行计划的方式和影响因素的相关文章

SQL点滴27—性能分析之执行计划

原文:SQL点滴27-性能分析之执行计划 一直想找一些关于SQL语句性能调试的权威参考,但是有参考未必就能够做好调试的工作.我深信实践中得到的经验是最珍贵的,书本知识只是一个引导.本篇来源于<Inside Microsoft SQL Server 2008>,有经验的高手尽管拍砖把.   这个部分将讲解一些性能分析工具,这些性能分许主要关注在执行计划.   缓存执行计划  SQL Server 2008提供了一些服务器对象来分析执行计划Sys.dm_exec_cached_plans:   

RDS SQL Server - 专题分享 - 巧用执行计划缓存之索引缺失

title: RDS SQL Server - 专题分享 - 巧用执行计划缓存之索引缺失 author: 风移 摘要 执行计划缓存是MSSQL Server内存管理十分重要的部分,同样如何巧用执行计划缓存来解决我们平时遇到的一系列问题也是一个值得深入研究的专题.这篇文章是如何巧用执行计划缓存的开篇,分享如何使用执行计划缓存来分析索引缺失(Missing Indexes). 问题引入 缺失索引是SQL Server CPU使用率居高不下的第一大杀手,也是SQL Server数据库非常大的潜在风险点

RDS SQL Server - 专题分享 - 巧用执行计划缓存之Single-used plans

背景引入 执行计划缓存是SQL Server内存管理中非常重要的特性,这篇系列文章我们探讨执行计划缓存设计中遇到的single-used plans问题,以及如何发现.如何定性和定量分析single-used plans带来的影响,最后我们使用两种方法来解决这个问题. 什么是Single-used Plans 要解释清楚什么是Single-used Plans,首先需要解释SQL语句执行计划缓存是什么?SQL Server执行每一条SQL语句之前,会从执行计划缓存内存中查看是否存在本条语句的执行

一次ORACLE SQL谓词跨界导致的执行计划不准

一次ORACLE SQL谓词跨界导致的执行计划不准 首先说明谓词跨界一般出现在日期类型中,打个比方你的统计数据是8月20号的,但是今天是8月28日,在这20号到28号之间日期是没有进入统计数据的, 这样可能导致,根据统计信息计算出来的COST异常的小,这样可能导致本来该走其他字段索引的语句走到时间索引上去,导致执行计划最终错误. 在10053中可以看到如下提示: as selectvity of out-of-range/non-existent value pred 以前多次遇到过,今天再次遇

RDS SQL Server - 专题分享 - 巧用执行计划缓存之Table Scan

背景引入 执行计划中的Table Scan或者是Clustered Index Scan会导致非常低下的查询性能,尤其是对于大表或者超大表.执行计划缓存是SQL Server内存管理中非常重要的特性,这篇系列文章我们探讨如何从执行计划缓存的角度来发现RDS SQL数据库引擎中的Table Scan行为,以及与之相应SQL查询语句详细信息. 问题分析 其实,我们大家都知道,Table Scan或者Clustered Index Scan是关系型数据库查询性能很差的一种表扫描查询方式,如果在数据库引

RDS SQL Server - 专题分享 - 巧用执行计划缓存之执行计划编译

背景引入 执行计划缓存是SQL Server内存管理中非常重要的特性,这篇文章是巧用执行计划缓存系列文章之五,探讨如何从执行计划缓存中获取查询语句执行计划编译的性能消耗,比如: 编译时间消耗 编译CPU消耗 编译内存消耗 缓存大小消耗 等等一系列非常有价值的统计信息. 什么是执行计划编译 SQL查询语句在提交到SQL Server主机服务之后,数据查询访问动作发生之前,SQL Server的编译器需要将查询语句进行编译,然后查询优化器生成最优执行计划.而这个编译和最优执行计划选择的过程,

SQL Server查询优化器:最佳执行计划

我们知道,查询优化器的基本的目标就是为我们的查询语句找出一个比较高效的执行计划.即使是一个非常简单的查询,也会存在很多的不同方式去访问数 据,而这些不同的方式都是可以得到相同的结果的,所以,查询优化器必须要很"明智的"从这些大量的执行计划中找出了一个"最佳"的出来. 前一篇:浅析SQL Server查询优化器的工作原理 为了得到最好的计划,查询优化器必须在某些条件的限制下,尽可能多的创建和评估大量的候选执行计划.看到这里,就有一点需要注意了"查询优化器是尽

RDS SQL Server - 专题分享 - 巧用执行计划缓存之数据类型隐式转换

摘要 SQL Server数据库基表数据类型隐式转换,会导致Index Scan或者Clustered Index Scan的问题,这篇文章分享如何巧用执行计划缓存来发现数据类型隐式转换的查询语句,从而可以有针对性的优化查询,解决高CPU使用率的问题. 问题引入 测试环境 为了更好的展示从执行计划缓存缓存中找出导致数据类型转化的查询语句,我们先建立测试环境. -- Create testing database IF DB_ID('TestDb') IS NULL CREATE DATABASE

RDS SQL Server - 专题分享 - 巧用执行计划缓存之Key Lookup

背景引入 执行计划缓存是SQL Server内存管理中非常重要的特性,这篇文章是巧用执行计划缓存系列文章之四,探讨什么是Key Lookup操作,如何从执行计划缓存中发现Key Lookup问题,以及如何解决这个问题. 什么是Key Lookup Key Lookup操作是指执行计划通过表的索引查找字段列的书签查找方式.Key Lookup发生在当查询语句使用Index Seek(或者Index Scan)的同时,又需要查找Index中没有完全包含的额外字段列,这时SQL Server必须回过头