越來越發現自己不懂的還是不少--繫結變數

      我從學習資料庫開始就知道，硬解析會有很大問題。我接觸的資料庫中貌似只有Oracle會涉及到這個。有的時候我自同等環境下（硬體配置和場景）測試下來Oracle會由於其他資料庫的資料，我有時候就在想會不會這就是軟解析和軟軟解析帶來的效果？
      不過十幾年工作下來，幾乎沒有遇到過硬解析帶來的問題。但是試問蒼天饒過誰。我這就遇到了。而且還重新整理了我對繫結變數的一些新的認知。

      發現一個系統，故障時段硬解析很高。對比了一下故障後的硬解析下降了1000倍。這是很驚人的。

      發現問題時候有一些SQL的版本較高有90多個，雖然比起網上有些幾百個的來說不算多，但是幾十個也不少了。我們都知道不繫結變數是什麼樣子的（就是寫入實際引數），我也知道繫結變數多了會怎麼樣（以前遇到過超過65535個資料庫就當機的）。但是其實我們一般都忽略繫結失敗的情況。查詢 V$SQL_SHARED_CURSOR，最後的reason裡面記錄了為什麼失敗。在這個reason之前有幾十個欄位每個都是一種原因。比如這種：

。 reason是這些的彙總。也就是說使用繫結變數不一樣就是繫結變數了，還有幾十種可能失敗，失敗了還是要硬解析的。

       之前沒怎麼關注過這些，可能有人會覺得不專業。其實資料庫博大精深，越學習越發現要學習的太多了，以前學習的還不夠。其實很多時候我們都是知道什麼是對的，怎麼做對就好了。這樣其實是簡單的。現在不同，是要了解稀奇古怪的錯（之所以有這些錯，是因為沒聽正確的做法，就導致了各式各樣的問題）。這次看到一個SQL在share_pool中佔據了將近2G。  你說這有天理嗎？

     我一直說只有我想不到的，沒有開發做不到的。