最適化してくれないDB2の最適化処理(解決編)
http://blogs.wankuma.com/hatsune/archive/2007/09/20/97109.aspx
上記エントリで報告をした問題ですが、その後、解決をしておりますので報告します。
問題が発生する例:
- 主キーが(日付、通番)
- データ分布として、[日付]値が２～３日くらい
- DB2の最適化を動かしている
- ⇒実行プランがTABLE SCAN
問題回避の例:
- 主キーが(通番、日付)
- データ分布として、[日付]値が２～３日くらい
- DB2の最適化を動かしている
- ⇒実行プランがINDEX SCAN
つまり、主キーの第一項目のカーディナリティ度が低いとINDEX SCANではなくTABLE SCANが行われるようなのです。
確かに、B-Treeインデックスはカーディナリティ度が高い場合に効果が高いですが、低いからといってTABLE SCANが良いとは限りません。実際、データを入れた直後で最適化を動かしていないときの実行プランはINDEX SCANで最適化を動かしてTABLE SCANになったら実行時間が10倍になるという測定結果も得ていました。
このような問題は、問題回避の例にあるようにプログラムコードを一切変えずにDB側の主キー変更のみで本来想定していた動きになり、無事稼動しております。
この問題解決はDB管理者とアプリ開発者が一致団結して問題解決にあたった成果であり、DB管理者が「アプリのつくりが悪い」、アプリ開発者が「いや、コードに悪いところは見当たらない」などと言っているようでは解決に至らなかったと思います。
DB管理者（というかDB設計）とアプリ開発との両方に関わる事が最近は多かったのですが、久々にDB管理者（DB設計者）が管轄外にいるプロジェクトでしたが、敵対するのではなく協調する事が大切だと再認識させられました。