Adaptive Cursor Sharing

先說說為什麼要搞出Adaptive Cursor Sharing這麼個東西。

11G以前一直存在一個問題，就是SQL在第一次硬解析的時候，最佳化器會窺探繫結變數的值，根據這個值來生成執行計劃。其實對於資料均勻分佈的情況來說，這個窺探也沒啥大問題，之所以說沒啥大問題，其實還是有我問題，我有點羅嗦了，那是因為範圍查詢的話情況就不一樣了，即使你的單個值沒傾斜分佈，但是範圍來說，也可能存在資料傾斜。比如你的id欄位最小值是1，最大值是1W，但是從2-9000都是沒有值的，那麼這樣的情況，如果你對id進行範圍查詢，也會涉及到執行計劃依賴於你傳輸的繫結變數。由於11G以前，在第一次窺探玩繫結變數後，執行計劃就產生在共享池裡了，後續的同樣的SQL都會使用這個執行計劃，而不去管傳入的值到底是什麼，現在的執行計劃是不適合這個變數值。

我很早就思考過這個問題，要解決這個問題，面臨幾個要解決的難題：

1）既然他們的執行計劃對繫結變數敏感，那麼就對有直方圖的列，每次都窺探他的值，如果執行計劃有變化，那麼就新生成一個執行計劃

2）上面的如果可行，那麼問題來了，現在對於這個SQL有2個執行計劃了，可是對於後續的SQL也還是每次都要去窺探繫結變數的值，然後生成執行計劃跟現有的比，還是有什麼巧妙的辦法？ORACLE搞了一個基數的概念出來，也就是v$sql_cs_selectivity 這個試圖內記錄的內容。對每個有資料傾斜的列計算一個選擇率出來，只要在某個選擇率範圍內的，就可以直接複用這個執行計劃。比如id=1執行計劃走了索引，選擇率是0.1，id=2經過計算也走了索引，選擇率是0.5，那麼後續來的所有SQL，經過計算後，只要選擇率在0.1-0.5之間的，都可以直接複用這個執行計劃。

上面的想法貌似不錯，但是存在一些問題：

1）每次都要對SQL裡涉及到直方圖的列，都要去窺探它的繫結變數，計算選擇率，代價還是比較高啊。其實對於大多數的列，即使存在直方圖，他們的執行計劃也是一樣的。為了解決這個問題，ORACLE設計出來了is_bind_sensitive，v$sql_cs_histogram  兩個東東，第一個值代表了這個值對於繫結變數是否敏感的，第二個檢視的作用，主要是用在如果由於這個列上的值的不同，導致結果集大範圍波動的，就在這個檢視的相關條目裡標記。

-----未完，待續