有時候,一些sql語句選擇了錯誤的執行計畫,與這個語句硬分析的時候peeking到的繫結變數值相關,這個繫結變數值對於問題的診斷是至關重要的,你當然可以根據一些別的線索來確定次優的執行計畫是因為硬分析時peeking到了非典型值,但如果能明確的顯示硬分析時peeking到的繫結變數值是最好的,其實確實是記錄了的:
資料庫版本:10.2.0.4
sql> select * from table(dbms_xplan.display_awr(sql_id=> '0763n191h71at',plan_hash_value=>1495544113 ,db_id=>2571538002 ,format=> 'advanced'));
select * from table(dbms_xplan.display_awr(sql_id=> '0763n191h71at',plan_hash_value=>1495544113 ,db_id=>2571538002 ,format=> 'advanced'))
ora-00907: missing right parenthesis
不知道這種呼叫形式為什麼會報錯.不過下面的呼叫形式是沒有問題的.
select * from table(dbms_xplan.display_awr('0763n191h71at',1495544113,2571538002,'advanced'));
select count(*) from product p, catalogrelateproduct catap where catap.catalogid = :b1
and catap.productid = p.id and p.publishstatus = 3
peeked binds (identified by position):
--------------------------------------
1 - :b1 (number): 122
mysql 生成執行計畫 MySQL執行計畫
和很多其他關係型資料庫不通，mysql並不會在生成查詢位元組碼來執行查詢。mysql生成查詢的一棵指令樹，然後通過儲存引擎執行完成這棵指令樹並返回結果。最終的執行計畫包含了重構查詢的全部資訊。如果某個查詢執行explain extended 之後，在執行show warnings，就可以看到重構出的...
sybase 檢視執行計畫
檢視語句的執行計畫 set showplan on set noexec on go select go set showplan off set noexec off go檢視儲存過程執行計畫 set showplan on go exec sp name go set showplan off ...
SybaseIQ 檢視執行計畫
在效能調優工作中，首要的事情是找出效能瓶頸。而針對資料庫應用，由於商用資料庫對上層應用來說是個黑盒，所以往往需要借助資料庫的一些介面或工具來了解資料庫的具體行為，並結合相關知識和業務進行調測。簡單來說，資料庫在執行乙個查詢之前，會為該查詢生成乙個最優 至少它這樣認為 的查詢計畫 query plan...