前段時間，在項目中碰到一個相當棘手的問題。我在寫一張報表時需要查詢客戶數據庫中已存在的視圖（是早期開發就有的）,相對應的銷售表中已有上千萬條數據，寫完后台邏輯將對應數據查出來沒任何問題。但是在界面上再點擊查詢按鈕。問題就來了：頁面直接卡死。
排除掉其他常見問題，例如語句性能，索引，緩存等等。最后發現奇怪的現象，正常來講同樣的一條SQL查詢語句，根據執行計划，第一次查詢完以后，后續再執行相同的語句應該很快才對。可是，現實卻是第一次查詢不慢（優化后2秒內查詢），第二次以后就掛掉。困擾了好久不知道問題所在，也向相關群里的大牛去咨詢也得不到結果。（數據庫為oracle11G，項目為.net EF開發模式。）
最后求助團隊老大，老大找來專業的DBA終於找出原因。
其實，算是Oracle11G的一個BUG。。。
11.2開始Oracle有了一種新的特性Cardinality Feedback，Cardinality Feedback是一個優化器自動優化的過程，優化器會自動修正重復執行的查詢的執行計划。對於一些復雜的查詢，比如多字段條件，字符串范圍比較，數據SKEW等等，以及缺乏統計信息，優化器可能不能夠產生一個完全准確的基數估計, 如丟失或統計數據不准確，或復雜的謂詞的基數估計。cardinality feedback 就是基於這一原因而產生的。_optimizer_use_feedback參數默認是TRUE，即開啟Cardinality Feedback，FALSE為關閉Cardinality feedback。由於在11GR2中Cardinality feedback生效存在很多限制且BUG較多，故沒必要啟用。
上段話是同事知道了原因后整理出來了的。 也就是說要關閉oracle的一個參數,對於結構上不復雜的語句，其實是看不到什么影響的。
alter system set "_optimizer_use_feedback"=false;
可以以一下方式驗證參數是否真正關閉。
SELECT x.ksppinm NAME, y.ksppstvl VALUE, x.ksppdesc describe FROM SYS.x$ksppi x, SYS.x$ksppcv y
WHERE x.inst_id = USERENV ('Instance') AND y.inst_id = USERENV ('Instance') AND
x.indx = y.indx AND x.ksppinm LIKE '%optimizer_use_feedback%';
結果：參數關閉后，同樣的語句，多次執行，已經不再會掛掉，跟數據庫上千萬的數據沒有多大關系，每次執行可以保證在兩秒左右。至此問題總算能解決。