周末，繼續放輕松，了解點常識。
經常在客戶的生産系統發現_gby_hash_aggregation_enabled 這個參數被設定成false，對于一般的中小系統，資料量相對較少，這個參數的影響不會太大。如果資料量比較大，性能的差距就比較明顯了，下面是在某個客戶現場實測的資料。
設定 _gby_hash_aggregation_enabled = false，SQL執行時間接近10分鐘：
設定 _gby_hash_aggregation_enabled = TRUE，SQL執行時間5分鐘多一點，性能相差接近1倍：
注：為了減少資料緩存産生的誤差，每個SQL都執行了兩次，時間相差可以忽略不計。
再來看看兩種情況的執行計劃對比：
_gby_hash_aggregation_enabled = false，使用Sort group by：
_gby_hash_aggregation_enabled = True，使用Hash group by：
這就是為什麼不建議将一些性能相關的優化器參數關閉的原因了。
_gby_hash_aggregation_enabled 這個隐含參數在10g的較早版本可能存在bug，被設定成了false；很多客戶更新到11g後，仍保持該參數為false，建議檢查bug修複清單，如果相關bug已修複，建議設定該參數為TRUE。
如果遇到某些特定SQL确實遇到了bug，可以在SQL級别關閉該參數：
如 select /*+ OPT_PARAM('_gby_hash_aggregation_enabled' 'false') */ ......
也可以使用sql profile，不用修改SQL代碼，也可以讓參數設定生效。