『壹』 oracle sql 查詢我使用自已寫的函數查詢很快，加了函數做條件就很慢是為什麼
慢是因為
對於 幾十萬條記錄左右,
你那個 test(a) 函數, 需要執行 很多次， 每行執行一次， 然後判斷 LIKE '%123%'
至於：
select a,b, test(a) c from demo; --只這樣查很快
我估計你使用的是 PLSQL Developer。
查詢的時候， 默認是查詢第一頁， 因此很快。
因為只顯示少部分行。
例如一頁20行的話， 那麼也就執行你那個函數 20次。
『貳』 oracle 查詢語句 第一次執行很快，第二次執行就很慢 。是什麼原因
oracle sql 第一次查詢快， 以後查詢慢
大多數情況下，用oracle， 第一次查詢慢， 第二次查詢肯定比第二次查詢快對吧，
但對於這種情況，第一次查詢快， 以後查詢慢。
Cardinality Feedback基數反饋， 是版本11.2中引入的關於SQL 性能優化的新特性，該特性主要針對 統計信息陳舊、無直方圖或雖然有直方圖但仍基數計算不準確的情況， Cardinality基數的計算直接影響到後續的JOIN COST等重要的成本計算評估，造成CBO選擇不當的執行計劃。以上是Cardinality Feedback特性引入的初衷。
基數反饋多少也造成了一些麻煩，典型的情況是測試語句性能時，第一次的性能最好，之後再運行其性能變差。
如何禁用Cardinality Feedback基數反饋
對於這些」惹火」特性，為了stable，往往考慮關閉該特性。
可以通過多種方法禁用該特性
1. 使用 _optimizer_use_feedback 隱藏參數
session 級別
SQL> alter session set 「_optimizer_use_feedback」=false;
會話已更改。
system級別
SQL> alter system set 「_optimizer_use_feedback」=false;
系統已更改。
————————————————
原文鏈接：https://blog.csdn.net/demonson/article/details/80522150
『叄』 Oracle 視圖查詢有的時候很慢,有的時候查詢很快
這種情況有很多可能性，首先，你的伺服器的負載情況會影響到你的數據讀取速度的，如果資料庫伺服器執行的進程過多，會導致查詢速度下降很多。
另外，第一次執行同一個SQL的時候，都會比較慢一些，再次執行的時候，由於數據等還在內存內，會速度快很多。
再者，在Oracle中，有共享SQL語句的機制，在第一次解析之後, ORACLE將SQL語句存放在內存中.這塊位於系統全局區域SGA(system global area)的共享池(shared buffer pool)中的內存可以被所有的資料庫用戶共享. 因此,當你執行一個SQL語句(有時被稱為一個游標)時,如果它 和之前的執行過的語句完全相同, ORACLE就能很快獲得已經被解析的語句以及最好的執行路徑. 這樣也會大大的提高效率。
『肆』 oracle資料庫約200W數據查詢非常慢，查詢需要10幾秒，經常查詢超時，這個正常嗎有沒有什麼好的辦法解決
先確認一下問題，是代碼操作的查詢還是連接oracle工具操作的查詢，優化大數據量主要先從三兩方式入手，第一，建索引，這個有講究：主要是針於你的查詢條件(即是在where後面的欄位建索引，有幾個條件欄位就建幾個，如果有組合條件查詢，那建聯合索引)。第二點，就是按表中的數據，進行表分區，如按時間段進行分區，按區域進行分區，按單位或部門進行分區等。減少全表掃描。三，檢查一下表空間大少。
『伍』 oracle資料庫系統視圖查詢慢
PB連接資料庫右鍵打開一張表的時候要刷新挺多數據的，需要讀取一些系統表，獲取對象數據結構信息，並且生成一個數據窗口展現數據。這個過程消耗時間。
檢查一下如下幾個情況：
1、使用的Oracle驅動是否版本匹配，例如：你使用Oracle8的驅動連接Oracle10的資料庫，從訪問的優化性來將，是有差別的，可能會影響效率；
2、把視圖在PL/SQL工具中進行執行計劃的查詢，檢查其性能是否有問題，例如：索引使用不當等情況；
3、程序編譯之後執行一下看看，性能是否依舊較低？開發模式下，編譯器沒有針對性的優化，可能影響到效率。
從開發階段就開始關注效率，這個是很好的習慣。希望我的回答能對你有幫助。
『陸』 oracle 查詢的sql語句特別慢，是什麼原因，是or特別慢嗎，用什麼優化，急急急！！！
把查詢計劃的內容發出來，你這一大堆代碼誰能看出來啥啊。看你的代碼這么長，條件那麼多，語句用了函數，很多低效的or,not in等操作，另外還用了group by，order by，左右連接等等，如果表數據量很大的話，你這個語句性能不好是預料中的事情。如果你這條語句無法優化，建議從調整表結構角度考慮
『柒』 oracle資料庫運行sql很卡很慢很頓，看等待事件都是cursor:pin s on x,這是啥
詳解cursor: pin S wait on X等待事件 『cursor: pin * events』等待事件 該類等待事件一般是為了pin相關的子游標 『Cursor: pin S on X』 最常見的等待事件， 進程為了共享操作例如執行pin游標而以SHRD S mode申請mutex， 但是未立即獲得。原因是該游標被其他進程以EXCL X mode 持有了。 實際該 cursor: pin S wait on X等待事件往往是由於其他因素誘發的。Mutex爭用僅僅是問題的症狀，但根本原因需要Database Consultant 進一步挖掘。 下面我們列出一些已知的常見案例， 在這些例子中可以看到 我上面提到的 Mutex的爭用僅僅是偽爭用: 過多的子游標 High Version Counts 過多的子游標版本Version Count可能導致Mutex 爭用，一般一個SQL的Version Count不要高於500。 檢查High Version Count很簡單， 在AWR里就有SQL ordered by High Version Count，也可以寫SQL查V$SQL、V$SQLAREA 昂貴的X$、V$視圖查詢 一些對於V$、X$視圖的查詢，需要訪問X$KGL*之類的fixed table，可能觸發Mutex爭用。 Mutex持有者得不到CPU Mutex持有者若得不到足夠的CPU片可能一直阻塞他人，直到它拿到需要的CPU。 這種情況可能由於OS操作系統的實際情況或者使用Resource Manager而引起。需要配合AWR中的Host CPU、Instance CPu一起看。 已經被KILLED的SESSION仍持有Mutex 當session正持有Mutex，而其對應的Process被強制KILL掉， 則直到PMON徹底清理掉該Dead Process並釋放Mutex，其他session才能不再等待。 診斷該類問題，最好能檢查PMON的TRACE。 當然也存在部分BUG會導致PMON清理過程非常慢。 舉例來說，bug 9312879描述了一種場景：PMON 需要獲得某個Mutex以便清理某個dead process，但是該Mutex又被其他進程持有，則PMON甚至無法開始真正清理並釋放Mutex。 如果自己搞不定可以找ASKMACLEAN專業ORACLE優化團隊成員幫您搞定!