这篇外传之前有这么几篇文章：
《一个执行计划异常变更的案例 - 前传》
《一个执行计划异常变更的案例 - 外传之绑定变量窥探》
上一篇文章介绍了绑定变量以及11g之前绑定变量窥探的影响，这篇文章会介绍几种查看绑定变量值的方法。
上篇文章我们说了，绑定变量实际是一些占位符，可以让仅查询条件不同的SQL语句可以重用解析树和执行计划，避免硬解析。绑定变量窥探则是第一次执行SQL硬解析时，会窥探使用的绑定变量值，根据该值的分布特征，选择更合适的执行计划，副作用就是如果绑定变量列值分布不均匀，由于只有第一次硬解析才会窥探，所以可能接下来的SQL执行会选择错误的执行计划。
有时可能我们需要查看某条SQL使用了什么绑定变量值，导致执行计划未用我们认为最佳的一种。
方法一：10046
使用level=4的10046事件，查看生成的trace文件，
可以看出绑定变量值是’Z’。
方法二：v$sql_bind_capture
首先找出SQL对应的sql_id，
从v$sql_bind_capture可以看出两个绑定变量占位符以及对应的值，
这里有一点值得注意的就是，DATATYPE_STRING列的描述是“绑定变量数据类型的文本表示”，开始我认为就是绑定变量字段的数据类型，但实际看来不是，DATATYPE_STRING列只是来告诉你绑定变量列是字符型，还是数值型。
我们此时换一下绑定变量值，发现vsql_bind_capture信息未变，dbsnake的书中曾说过当SQL执行硬解析时绑定变量值被捕获，并可从视图v$sql_bind_capture中查询。
对于执行软解析/软软解析的SQL，默认情况下间隔15分钟才能被捕获，为了避免频繁捕获绑定变量值带来的系统性能开销，而且从常理上认为，既然使用了绑定变量，最佳方式就是值分布均匀，只需要SQL执行第一次硬解析时窥探一下，后续执行的SQL执行计划应该比较稳定，因此只要能比较实时地查看第一次绑定变量值即可。间隔15分钟受隐藏参数_cursor_bind_capture_interval控制，默认值是900s，15分钟。
我们尝试将捕获绑定变量的间隔时间调短，该参数不支持session级别修改，
执行alter system级别操作，
等大约一分钟，此时可以从v$sql_bind_capture查询刚使用的绑定变量值，
方法三：AWR信息
(1) DBA_HIST_SQLBIND视图包含了v$sql_bind_capture的快照。
因此对应的SQL语句，和v$sql_bind_capture很像，
select name,datatype_string,value_string,datatype from DBA_HIST_SQLBIND where sql_id='...'
(2) 另一个视图，DBA_HIST_SQLSTAT记录了SQL统计信息的历史信息，他是基于一些标准，捕获来自于V$SQL的统计信息。可以使用如下SQL，
dbms_sqltune.extract_bind(bind_data,1).value_string bind1,
dbms_sqltune.extract_bind(bind_data,2).value_string bind2,
dbms_sqltune.extract_bind(bind_data,3).value_string bind3
from dba_hist_sqlstat
where sql_id = '...'
order by snap_
其中dbms_sqltune.extract_bind(bind_data,1).value_string取决于SQL中绑定变量的数量。
第一次执行这两条SQL时，并未有任何结果返回，我猜测可能是这条SQL不符合AWR采集的标准。从MOS中查到这篇文章：《How to Control the Set of Top SQLs Captured During AWR Snapshot Generation (文档 ID )》，用其中的方法修改下AWR采集topnsql参数，
此时重新执行SQL，默认AWR会一小时采集一次，此时可以手工采集AWR快照，
此时再次查询DBA_HIST_SQLBIND，
再次查询DBA_HIST_SQLSTAT，
方法四：EM？
本以为任何可以使用SQL执行，都可以从EM中找到相应的界面，但未找出绑定变量值可以检索的地方，若是有朋友知道，可以告诉我们。
绑定变量值可以使用很多方法获取，这里只是列举了三种最常见的方法，我从网上看到有朋友还有用wrhsqlstat、vsql等视图查询的例子，没有深究，我觉得碰见问题时，可以快速使用一些常用的方法解决问题就可以了，当然时间充裕的话，建议还是多从原理层了解一些，做到触类旁通则最好。
本文已收录于以下专栏：
相关文章推荐
上一篇文章《一个执行计划异常变更的案例 - 前传》(http://blog.csdn.net/bisal/article/details/)，介绍了一次执行计划异常变更的案例现象，这两...
之前的几篇文章：
《一个执行计划异常变更的案例 - 前传》
《一个执行计划异常变更的案例 - 外传之绑定变量窥探》
《一个执行计划异常变更的案例 - 外传之查看绑定变量值的几种方法》
《一个执...
程序员升职加薪指南！还缺一个“证”！
CSDN出品，立即查看！
之前的几篇文章：
《一个执行计划异常变更的案例 - 前传》
《一个执行计划异常变更的案例 - 外传之绑定变量窥探》
《一个执行计划异常变更的案例 - 外传之查看绑定变量值的几种方法》
《一个执...
今天单位值班，有一些时间可以继续完成这篇连载文章。首先祝所有朋友新年快乐！感谢你们在这一年当中对我文章的关注和指点，来年我们共同继续努力！之前的几篇文章：
《一个执行计划异常变更的案例 - 前传》...
之前的几篇文章：
《一个执行计划异常变更的案例 - 前传》
《一个执行计划异常变更的案例 - 外传之绑定变量窥探》
《一个执行计划异常变更的案例 - 外传之查看绑定变量值的几种方法》
《一个执...
刚做完一次网络切换支持，得空写一篇，其实今儿取了巧，这篇文章是之前写过的，碰巧又是这次“执行计划异常变更”案例涉及的一个知识点，所以再次翻出来。之前的几篇文章：
《一个执行计划异常变更的案例 - 前...
之前的几篇文章：
《一个执行计划异常变更的案例 - 前传》
《一个执行计划异常变更的案例 - 外传之绑定变量窥探》
《一个执行计划异常变更的案例 - 外传之查看绑定变量值的几种方法》
《一个执...
之前的几篇文章：
《一个执行计划异常变更的案例 - 前传》
《一个执行计划异常变更的案例 - 外传之绑定变量窥探》
《一个执行计划异常变更的案例 - 外传之查看绑定变量值的几种方法》
《一个执...
今天快下班的时候，几位兄弟来聊一个问题，大致是昨天应用使用的数据库突然出现性能问题，DBA发现有一些delete语句执行时间骤长，消耗大量系统资源，导致应用响应时间变长积Q。目前掌握的信息如下：
之前的几篇文章：
《一个执行计划异常变更的案例 - 前传》
《一个执行计划异常变更的案例 - 外传之绑定变量窥探》
《一个执行计划异常变更的案例 - 外传之查看绑定变量值的几种方法》
《一个执...
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)温馨提示！由于新浪微博认证机制调整，您的新浪微博帐号绑定已过期，请重新绑定！&&|&&
LOFTER精选
网易考拉推荐
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
如何入手呢?
在刚进入IT行业时，我知道SQL Server的基础只是。说实话，向客户承诺检查系统的时候，我还没有一点入手的头绪。不过我相信我可以通过GOOGL和BOL来获取相应的信息。
我阅读了一些关于SQL Server的书籍，BOL，以及在网上搜索的信息。于是我知道了“显示执行计划”的概念。可以在查询管理器中将该选项的开关设置为ON。“显示执行计划”是一个图形化工具，可以帮助开发者和DBA分析，优化查询，从而改善性能。
“显示执行计划”中不同的任务具有不同的图标。本文中我主要对“Table Scan”、“Index Scan”、“Index Seek”、“Cluster Index Scan”以及“Clustered Index Seek”感兴趣。也许在以后，可以对别的任务进行另外介绍。
时间以F1方程式的速度开始流逝，我觉得该是我全面理解“Table Scan”、“Index Scan”、“Index Seek”、“Clustered Index Scan”、和“Clustered Index Seek”如何工作的时候了。
我准备开始分析并优化我的查询。在分析之前，我想到了一些问题。
MS-SQL Server什么时候使用"Table Scan"?
MS-SQL Server什么时候使用"Index Scan"?
MS-SQL Server什么时候使用"Index Seek"?
MS-SQL Server什么时候使用"Clustered Index Scan"?
MS-SQL Server什么时候使用"Clustered Index Seek"?
我主要关注SQL Server是根据什么来使用“执行计划”分析查询的。在经过一段时间学习后，我了解了一些相关知识。这些知识应该对开发和DBA新手有帮助。于是我决定写这篇文章，共享我的知识以帮助别人来理解“执行计划”。
如果你喜欢，可以慢慢读完，也可以在SQL Server上，模拟我下面做的实验。
为了解释“显示执行计划”中的“Table Scan”、“Index Scan”、“Index Seek”、“Clustered Index Scan”和“Clustered Index Seek”，先创建新表，并添加一些示例数据进去。下面是创建新表的脚本：
Create Table PerformanceIssue(&&&&PRID UniqueIdentifier NOT NULL,&&&&PRCode Int NOT NULL,&&&&PRDesc Varchar (100) NOT NULL)ON [PRIMARY]
表创建后需要添加一些数据。使用下面的脚本添加100,000条记录进去。脚本执行时间可能比较长，请耐心等待其执行完毕。
Declare @Loop IntDeclare @PRID UniqueIdentifierDeclare @ PRDesc Varchar (100)Set @Loop = 1Set @ PRDesc = ''WHILE @Loop &= 100000BEGIN&& Set @PRID = NewID()&& Set @PRDesc = ' PerformanceIssue - ' + Convert( Varchar(10),@Loop )&& Insert Into PerformanceIssue Values (@PRID, @Loop, @PRDesc)&& Set @Loop = @Loop + 1END
脚本成功执行后，数据就添加进去了。
用下面语句来看一下表的内容：
Select PRID, PRCode, PRDescFrom PerformanceIssueGO
由于记录较长，因此这里就不列出查询结果了。
正如我前面讲到，我想解释何时会有“Table Scan”、“Index Scan”、“Index Seek”、“Clustered Index Scan”和“Clustered Index Seek”。上述哪个会改善性能呢？
当SQL Server返回数据时，我们想知道SQL Server采取何种扫描机制来协助获取数据。首先看一下“Table Scan”。我们想了解什么时候“Table Scan”会产生。
选择“显示执行计划”或者使用热键“Alt + Q”来激活“显示执行计划”，当然也可以用快捷键“Ctrl+K”。
看一下执行下面查询后的“执行计划”结果。
Select PRID, PRCode, PRDesc From PerformanceIssueGO
上面的“执行计划”中，SQL Server用到了“Table Scan”。我问自己为什么会有“Table Scan”，SQL Server是根据什么来使用该方法的。难道是因为我想获取所有100,000条记录吗？于是我换了一个角度进行思考，如果来避免查询中出现“Table Scan”呢？此时我对SQL Server的扫描机制还不是很清楚，那么该如何优化查询呢？下面的SELECT查询中仅选择两列：[PRID, PRCode]。
Select PRID, PRCodeFrom PerformanceIssueGO
查询执行后，执行计划和第一个查询一样。于是将查询改变为只检索一个字段 [PRID]。
Select PRID From PerformanceIssueGO
查询执行后，执行计划仍然和第一个查询的相同。对“Estimated row size”属性不需要太大关注。意思我立刻决定只获取一条记录，看看执行计划会如何。查询语句如下：
Select PRID, PRCode, PRDesc From PerformanceIssueWhere PRID = 'D386C151-5F74-4C2A-B527-86FEF9712955'-- PRID GUID value might be differ in your machineGO
执行完成后，执行计划显示：
查询仍然使用了“Table Scan”方法来显示数据。
那么，我需要想其它办法来避免“Table Scan”。首先我想到应该给表加上索引。于是我在PRID字段上创建非聚集索引。添加了索引后是否就能避免“Table Scan”？下面我们开始讨论关于“Index Scan”和“Index Seek”的主题。
Index Scan 和 Index Seek
首先在PRID字段上创建非聚集索引。
CREATE UNIQUE NONCLUSTERED INDEX UNC_PRIDON PerformanceIssue (PRID)GO
本文假定读者已经知道非聚集索引如何工作的知识。了解非聚集索引更详细的信息，请阅读BOL相关主题，也可参看 。下面我们详细讲述“Index Scan”是如何工作的。
执行下面语句并查看执行计划的结果。
Select PRID, PRCode, PRDesc From PerformanceIssueGO
奇怪了，“Table Scan”仍然用到了。为什么SQL Server没有用到那个非聚集索引？于是继续优化查询语句，选择检索两个字段 [PRID, PRCode] 。
Select PRID, PRCode From PerformanceIssueGO
执行结果是和上一个查询结果一摸一样。于是修改查询为只检索一个字段 [PRID] 。
Select PRID From PerformanceIssueGO
执行计划结果如下：
“Index Scan”在查询中被用到了，这很好。很自然，接下来的问题就是“Index Scan”什么时候会被用到。字段PRID上有一个索引，查询语句中选中的字段为PRID。执行查询的时候，SQL Server扫描索引页，因此用到了“Index Scan”方法。前面的查询中选择了有索引的和没有索引的字段，SQL Server无法使用“Index Scan”。当查询中只选择有索引的字段时，SQL Server就使用了“Index Scan”。我不清楚SQL Server底层到底是如何判断的，不过通过这些试验，我认为当查询中只选择有索引的字段时，SQL Server就使用“Index Scan”方法。
下面看“Index Seek”方法何时产生。当我看到“Seek”这个词时，第一反应就是条件查询这个主意。
我尝试三种不同的带WHERE语法的查询语句，以找出那种会用“Index Seek”。第一种语句如下：
Select PRID, PRCode, PRDesc From PerformanceIssueWhere PRCode = 8GO
结果显示，执行计划使用了“Table Scan”。
第二种语句如下：
Select PRID, PRCode, PRDescFrom PerformanceIssueWhere PRDesc = ' PerformanceIssue - 8'GO
执行计划仍然使用“Table Scan”方法。
第三种查询语句如下：
Select PRID, PRCode, PRDescFrom PerformanceIssue Where PRID = 'D386C151-5F74-4C2A-B527-86FEF9712955'-- PRID GUID value might be differ in your machineGO
查询用到了“Index Seek”和“Bookmark Lookup”方法。用到“Index Seek”是因为WHERE后面使用带索引的字段PRID来进行过滤。“Bookmark Lookup”方法被用到是因为查询中选择了没有索引的字段。如果去掉这两个没有索引的字段，那么“Bookmark Lookup”方法就可以去掉。当然如果只返回PRID字段，那么该查询就没什么意义了，因为WHERE语句后面已经给出PRID具体取值了。
我认为“Index Seek”在性能改善上比“Index Scan”和“Table Scan”要好，这主要表现在下面几个方面：
“Index Seek”不需要对表和索引页进行扫描；而“Table Scan”和“Index Scan”需要。
“Index Seek”利用“WHERE”来过滤获取的数据，这样比用“Index Scan”和“Table Scan”快很多。
当我完成这些测试后，我同事问我一个很有意思的问题：SQL Server什么时候使用“Clustered Index Scan”和“Clustered Index Seek”？下面对“Clustered Index Scan”和“Clustered Index Seek”进行实验。
我决定在PRCode上建一个聚集索引来测试“Clustered Index Scan”和“Clustered Index Seek”。
Clustered Index Scan & Clustered Index Seek
下面的脚本删除PRID字段上的索引，并在PRCode字段上创建聚集索引。
Drop Index PerformanceIssue.UNC_PRIDGOCREATE UNIQUE CLUSTERED INDEX UC_PRCodeON PerformanceIssue( PRCode)GO-------------Clustered index has been created successfully. Index has been created.
关于聚集索引的基础知识请查阅联机帮助的相关主题或者 。下面我们将重点放在“Clustered Index Scan”和“Clustered Index Seek”如何被使用上。
执行下面查询语句：
Select PRID, PRCode, PRDesc From PerformanceIssueGO
查询执行后，可以看到执行计划中用到了“Clustered Index Scan”。
下面用三种不同的WHERE方式来试验何时SQL Server会用到“Clustered Index Seek”。第一种形式如下：
Select PRID, PRCode, PRDesc From PerformanceIssueWhere PRDesc = ' PerformanceIssue - 8'GO
查询执行后，可以看到执行计划中用到了“Clustered Index Scan”。
第二种形式如下：
Select PRID, PRCode, PRDesc From PerformanceIssueWhere PRID = 'D386C151-5F74-4C2A-B527-86FEF9712955'-- PRID GUID value might be differ in your machineGO
查询执行后，发现执行计划中用到的仍然是“Clustered Index Scan”。
第三种形式：
Select PRID, PRCode, PRDesc From PerformanceIssueWhere PRCode = 8GO
这次执行计划用到了“Clustered Index Seek”。
当在WHERE后用到PRCode字段的时候，“Clustered Index Seek”被用到。执行计划对聚集索引表检索的时候，因为在选取的字段中，包括没有索引的字段，所以不用用到“Bookmark Lookup”方法。
我个人认为，从改善性能角度考虑，“Clustered Index Seek”比“Clustered Index Scan”和“Index Seek”要好。
“Clustered Index Seek”不需要扫描整个聚集索引页。
和“Index Scan”相比，对于检索选择的字段包含那些没有索引的字段时，“Clustered Index Seek”不会有“Bookmark Lookup”方法出现。
通过这些试验，我对执行计划的应用积累了实际经验。我知道哪种扫描机制可以提高性能，从而是的客户满意。
阅读(7198)|
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
历史上的今天
loftPermalink:'',
id:'fks_083064',
blogTitle:'关于SQL的执行计划/查看SQL语句的具体执行过程，工作原理',
blogAbstract:'
&&&& 刚开始用SQL Server的时候，我没有用显示执行计划来对查询进行分析。我曾经一直认为我递交的SQL查询都是最优的，而忽略了查询性能究竟如何，从而对“执行计划”重视不够。在我职业初期，我只要能获取数据就很开心，而不去考虑数据是如何返回的，“执行计划”对我的查询作了什么工作。我以为SQL Server会自己去处理查询的性能问题的。作为一个刚进入IT行业或者刚学到新技术的软件工程师，在编写代码前不太可能有时间去学习其实必须掌握的知识。也许这是因为IT行业竞争太激烈的缘故。
随着时间的流逝，数据库容量慢慢变大了。终于某天，客户对应用系统的查询性能感到不满意了。他面带怒容来找我，抱怨',
blogTag:'',
blogUrl:'blog/static/',
isPublished:1,
istop:false,
modifyTime:9,
publishTime:2,
permalink:'blog/static/',
commentCount:0,
mainCommentCount:0,
recommendCount:5,
bsrk:-100,
publisherId:0,
recomBlogHome:false,
currentRecomBlog:false,
attachmentsFileIds:[],
groupInfo:{},
friendstatus:'none',
followstatus:'unFollow',
pubSucc:'',
visitorProvince:'',
visitorCity:'',
visitorNewUser:false,
postAddInfo:{},
mset:'000',
remindgoodnightblog:false,
isBlackVisitor:false,
isShowYodaoAd:false,
hostIntro:'',
hmcon:'1',
selfRecomBlogCount:'0',
lofter_single:''
{list a as x}
{if x.moveFrom=='wap'}
{elseif x.moveFrom=='iphone'}
{elseif x.moveFrom=='android'}
{elseif x.moveFrom=='mobile'}
${a.selfIntro|escape}{if great260}${suplement}{/if}
{list a as x}
推荐过这篇日志的人：
{list a as x}
{if !!b&&b.length>0}
他们还推荐了：
{list b as y}
转载记录：
{list d as x}
{list a as x}
{list a as x}
{list a as x}
{list a as x}
{if x_index>4}{break}{/if}
${fn2(x.publishTime,'yyyy-MM-dd HH:mm:ss')}
{list a as x}
{if !!(blogDetail.preBlogPermalink)}
{if !!(blogDetail.nextBlogPermalink)}
{list a as x}
{if defined('newslist')&&newslist.length>0}
{list newslist as x}
{if x_index>7}{break}{/if}
{list a as x}
{var first_option =}
{list x.voteDetailList as voteToOption}
{if voteToOption==1}
{if first_option==false},{/if}&&“${b[voteToOption_index]}”&&
{if (x.role!="-1") },“我是${c[x.role]}”&&{/if}
&&&&&&&&${fn1(x.voteTime)}
{if x.userName==''}{/if}
网易公司版权所有&&
{list x.l as y}
{if defined('wl')}
{list wl as x}{/list}Oracle SQL执行计划变更的问题
oracle的执行计划经常会遭遇绑定变量窥视问题，导致执行计划变更，引起负载飙升，带来性能问题。
昨天有段时间，数据库负载报警，cpu使用率近100%。
今天通过awr发现，等待事件第一位的是read by other session；SQL Statistics 中几乎都是同一条sql排在第一：56s18gn1k19yp 该sql一个小时内执行了3700多次。
从这种迹象来看，应该是执行计划发生了变更。
oracle 10G中可以通过下面的三个视图查询到语句的历史执行信息：
DBA_HIST_SQL_PLAN
DBA_HIST_SQLSTAT
DBA_HIST_SNAPSHOT
查看语句的历史执行信息，是否发生变化，何时发生了变化。如果发生了变化,找出以前的执行计划,与当前的执行计划进行对比,有什么不同。
通过下面的sql查询执行计划是否发生变化：
select a.INSTANCE_NUMBER,a.snap_id,a.sql_id,a.plan_hash_value,b.begin_interval_time
from dba_hist_sqlstat a, dba_hist_snapshot b&
where sql_id ='56s18gn1k19yp'&
and a.snap_id = b.snap_id&
order by instance_number, snap_
SQL& select a.snap_id, a.sql_id, a.plan_hash_value,to_char(b.begin_interval_time,'yyyy-mm-dd hh24:mi:ss')&
& 2 &from dba_hist_sqlstat a, dba_hist_snapshot b&
& 3 &where sql_id ='56s18gn1k19yp'&
& 4 &and a.snap_id = b.snap_id&
& 5 &order by snap_ & &
& &SNAP_ID SQL_ID & & & &PLAN_HASH_VALUE TO_CHAR(B.BEGIN_INT
---------- ------------- --------------- -------------------
& & &gn1k19yp & & & 12-03-02 14:00:30
& & &gn1k19yp & & & 12-03-02 03:00:12
& & &gn1k19yp & & & 12-03-01 21:00:36
& & &gn1k19yp & & &
& & &gn1k19yp & & & 12-03-01 19:00:21
& & &gn1k19yp & & & 12-03-01 04:00:31
& & &gn1k19yp & & & 12-02-29 20:00:37
& & &gn1k19yp & & & 12-02-29 17:00:24
& & &gn1k19yp & & & 12-02-29 14:00:11
& & &gn1k19yp & & & 12-02-29 12:00:04
& & &gn1k19yp & & & 12-02-29 11:00:59
& & &gn1k19yp & & & 12-02-29 04:00:11
& & &gn1k19yp & & & 12-02-29 03:00:04
& & &gn1k19yp & & & 12-02-28 19:00:27
& & &gn1k19yp & & & 12-02-28 18:00:22
& & &gn1k19yp & & & 12-02-28 17:00:18
& & &gn1k19yp & & & 12-02-28 15:00:11
& & &gn1k19yp & & & 12-02-28 14:00:07
& & &gn1k19yp & & & 12-02-28 08:00:25
& & &gn1k19yp & & & 12-02-27 16:00:03
& & &gn1k19yp & & & 12-02-27 05:00:06
& & &gn1k19yp & & & 12-02-27 04:00:00
& & &gn1k19yp & & & 12-02-27 02:00:51
& & &gn1k19yp & & & 12-02-26 21:00:31
& & &gn1k19yp & & &
& & &gn1k19yp & & & 12-02-26 05:00:33
& & &gn1k19yp & & & 12-02-26 04:00:25
& & &gn1k19yp & & & 12-02-26 03:00:17
& & &gn1k19yp & & & 12-02-26 02:00:09
& & &gn1k19yp & & & 12-02-25 17:00:16
& & &gn1k19yp & & & 12-02-25 12:00:51
& & &gn1k19yp & & & 12-02-25 07:00:05
& & &gn1k19yp & & & 12-02-25 05:00:55
& & &gn1k19yp & & & 12-02-25 04:00:50
& & &gn1k19yp & & & 12-02-24 19:00:52
& & &gn1k19yp & & & 12-02-24 11:00:12
& & &gn1k19yp & & & 12-02-24 09:00:56
& & &gn1k19yp & & & 12-02-24 05:00:23
& & &gn1k19yp & & & 12-02-24 04:00:11
& & &gn1k19yp & & & 12-02-24 01:00:46
& & &gn1k19yp & & & 12-02-23 20:00:15
& & &gn1k19yp & & & 12-02-23 17:00:56
& & &gn1k19yp & & & 12-02-23 14:00:37
& & &gn1k19yp & & &
我们注意到最近一次3月1号20点左右，执行计划发生了变化。
具体查看这两种执行计划有什么区别：
select sql_id,plan_hash_value,id,operation,options,object_owner,object_name,depth,cost,timestamp&
from DBA_HIST_SQL_PLAN
where sql_id ='56s18gn1k19yp'&
and plan_hash_value in ();
SQL& select plan_hash_value,id,operation,options,object_name,depth,cost,timestamp
& 2 &from DBA_HIST_SQL_PLAN &
& 3 &where sql_id ='56s18gn1k19yp'&
& 4 &and plan_hash_value in ();
PLAN_HASH_VALUE &ID OPERATION & & & & & &OPTIONS & & & & & & &OBJECT_NAME & & & & & & & & & & DEPTH & & & COST TIMESTAMP
--------------- --- -------------------- -------------------- ------------------------------- ----- ---------- -------------------
& 0 SELECT STATEMENT & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & &0 & & & & 84
& 1 COUNT & & & & & & & &STOPKEY & & & & & & & & & & & & & & & & & & & & & & & & &1 & & & & & & 04:33:34
& 2 VIEW & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & &2 & & & & 84
& 3 SORT & & & & & & & & ORDER BY STOPKEY & & & & & & & & & & & & & & & & & & & & 3 & & & & 84
& 4 TABLE ACCESS & & & & BY INDEX ROWID & & & BLOG_USER & & & & & & & & & & & & & 4 & & & & &3
& 5 NESTED LOOPS & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & &5 & & & & 83
& 6 HASH JOIN & & & & & &OUTER & & & & & & & & & & & & & & & & & & & & & & & & & &6 & & & & 17
& 7 TABLE ACCESS & & & & BY INDEX ROWID & & & CIRCLE_PAPER_MAIN & & & & & & & & & 7 & & & & 13
& 8 INDEX & & & & & & & &RANGE SCAN & & & & & IDX_CIRCLE_PAPER_MAIN_CID & & & & & 8 & & & & &3
& 9 TABLE ACCESS & & & & BY INDEX ROWID & & & CIRCLE_DISCUSS_CLASS & & & & & & & &7 & & & & &3
04:33:34 & &
&10 INDEX & & & & & & & &RANGE SCAN & & & & & IDX_CIRCLE_DISCUSS_CLASS_CID & & & &8 & & & & &1
&11 INDEX & & & & & & & &RANGE SCAN & & & & & IDX_BLOG_USER_BLOGID & & & & & & & &6 & & & & &2
& & & & 0 SELECT STATEMENT & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & &0 & & & -22 15:54:33
& & & & 1 COUNT & & & & & & & &STOPKEY & & & & & & & & & & & & & & & & & & & & & & & & &1 & & & & & & 15:54:33
& & & & 2 VIEW & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & &2 & & & -22 15:54:33
& & & & 3 SORT & & & & & & & & ORDER BY STOPKEY & & & & & & & & & & & & & & & & & & & & 3 & & & -22 15:54:33
& & & & 4 HASH JOIN & & & & & &RIGHT OUTER & & & & & & & & & & & & & & & & & & & & & & &4 & & & -22 15:54:33
& & & & 5 TABLE ACCESS & & & & BY INDEX ROWID & & & CIRCLE_DISCUSS_CLASS & & & & & & & &5 & & & & &3
& & & & 6 INDEX & & & & & & & &RANGE SCAN & & & & & IDX_CIRCLE_DISCUSS_CLASS_CID & & & &6 & & & & &1
& & & & 7 HASH JOIN & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & 5 & & & -22 15:54:33
& & & & 8 TABLE ACCESS & & & & FULL & & & & & & & & CIRCLE_PAPER_MAIN & & & & & & & & & 6 & & & &953
& & & & 9 TABLE ACCESS & & & & FULL & & & & & & & & BLOG_USER & & & & & & & & & & & & & 6 & & & -22 15:54:33
我们从查询结果中可以看到不同：
plan_hash_value =
&--执行计划走索引
plan_hash_value =
--执行计划走全表扫描
使用coe_xfr_sql_profile.sql可以发现两种执行计划的效率(AVG_ET_SECS)：
SQL& @coe_xfr_sql_profile.sql
Parameter 1: & &
SQL_ID (required)
Enter value for 1: 56s18gn1k19yp
PLAN_HASH_VALUE AVG_ET_SECS
--------------- -----------
& & & &.037
& & & & & &24.646
Parameter 2:
PLAN_HASH_VALUE (required)
Enter value for 2:
如何固定执行计划：
10g推荐使用sql profile来固定执行计划，coe_xfr_sql_profile.sql的本质也是调用sql profile来固定执行计划的。
本文来自于无忧网客联盟