select AKB020,AKC190,AKC220,AAE072,AKC515,AKA135,AAC001,AKC516,AKC221,AAE040,AKC222,AKC223,AKA063,AKA065,AKC224,AKA113,AKC225,AKC226,AKC227,AKC228,AKC334,AKA068,AKC253,AKA069,AAE073,AKA064,AKA070,AKA097,AKC229,AKA071,AKA072,AKC202,AKA073,AKA076,AKC201,AKC325,AKC125,AAE100,AKC301,AKC127,AKC347,AKC384,AKC378,AKC379,AKC380,AKC381,AKC382,AKC383,AAE011,AAE036,OAE001,OAE300,OAE301,AKA609,AKC319,AKC163,AKA231,BKC228,AKA163 from kc22 where akb020 = :"SYS_B_0"and akc190 = :"SYS_B_1" and aae100 = :"SYS_B_2"
在pl/sql中秒出結果，在程式中死活通不過。
uj5u.com熱心網友回復：
程式中不能使用:"SYS_B_0"這種系結變數。而在PL/SQL中可以使用~
uj5u.com熱心網友回復：
那這種情況怎么破？ 以前是在一個服務上不行，切到另一個服務上可以了。運行了幾天又不行了。uj5u.com熱心網友回復：
要不你將這一段轉成占位符試試看：where akb020 = :"SYS_B_0"and akc190 = :"SYS_B_1" and aae100 = :"SYS_B_2"
改成：where akb020 = ? and akc190 = ? and aae100 = ?
uj5u.com熱心網友回復：
plsql dev所謂的秒出有可能是假象，在資料庫中執行的時候，他們可能走的是不一樣的路徑，如果樓主說的“通不過”是性能問題，或者說俗話說的“卡”，那么建議獲取執行計劃之后再來討論會比較好。另外，從SQL本身來看，隨著akb020、akc190、aae100三個條件的變化，有些可能會秒出，有些可能會卡，這和資料分布有關系，有些條件組合下在資料庫層，你可能也無力回天了，但如果無論這三個條件的值如何變化，符合條件的資料量都比較小的話，那么這個SQL可能還是可以被優化的，這要看執行計劃再做定奪。
有系結變數的SQL真實的執行計劃會比較難搞，有個相對方便點的方法（不過會遺漏謂詞資訊，也就是執行計劃中的條件詳細資訊會看不到）：
1、通過文本匹配，從v$sql從獲取該SQL的sql_id；
2、使用資料庫服務器端的$ORACLE_HOME/rdbms/admin/awrsqrpt.sql，根據提示輸入sql_id，或者該SQL真實的執行計劃
uj5u.com熱心網友回復：
如果程式一開始沒問題，跑了幾天有問題了，那就說明很可能是資料量的變化導致了性能的下降，如果不想獲取執行計劃，想碰碰運氣來解決這樣的問題，可以考慮最大的可能就是：SQL的執行計劃走了表掃描了，你沒有在三個條件上創建索引，可以試著在這三個欄位上創建組合索引解決這種問題。
uj5u.com熱心網友回復：
暫時解決了，加了強制索引，先湊合湊合吧。否則沒法報銷要引出民憤的uj5u.com熱心網友回復：
如果三個條件的值不斷變化，但是符合條件的資料量一直能穩定在一個比較小的量級，那么SQL中硬編碼INDEX提示也是個可行且不錯的方案。
另外我想了想，樓主你這種情況很可能是11g之后Oracle新引入的“cardinality feedback”（直譯：基數反饋）功能導致的，該功能簡單地講就是Oracle會根據SQL之前執行得到的基數情況來自動更改SQL的執行計劃，這個功能本意是好的，但在實際生產中，往往會捅了馬蜂窩，好在，這個功能可以通過隱藏引數_optimizer_use_feedback來關閉。
uj5u.com熱心網友回復：
如果不想加提示，其實可以通過sql profile來做類似的實作。
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/81494.html
標籤：高級技術
上一篇：sql 缺失運算式