オラクルSQLでTRIMを利用したらパフォーマンスが悪くなる_ブログ_zanmai.net

オラクルでTRIMを利用するSQLのパフォーマンスが劇的に低い現象が発生しました。開発段階にテーブルのレコード数が少ない時にSQLの重さがかじってませんでしたが、
本番に近いデータを入れた後に検証したら、検索が重くてほぼ動けない状態に落ちってしまった。原因は下記のようなSQLです。

select * from abc_tbl where TRIM(id)=#param_id# and del_flg <> '1';

上記のSQLで、インデックスを入れたけど、TRIMメソッドを利用のため、ORACLEのインデックス機能が利用できなくなって、パフォーマンスが非常に悪くなった
また、SQL中でカラムを演算したり、NULLと比較したら、ORやINを利用したりなどの原因でORACLEのインデックス機能を効けなくなり、SQLを重くなる現象が発生するケースも少なくありません。

悪い例：select * from demo_tbl where col1 / col2 > 1;←カラムを演算。
改善例：select * from demo_tbl where col1 > col2; 

悪い例：select * from demo_tbl where col1 != null;←NULLと比較
改善例：DB設計が悪い。デフォルト値が0や' '等に設計すれば、NULL比較を避ける。

悪い例：select * from demo_tbl where col1 in('abc','bcd','cdf');←INを利用。
改善例：select * from demo_tbl where col1 = 'abc'
UNION ALL
select * from demo_tbl where col1 = 'bcd'

悪い例：select * from demo_tbl where col1 = 'aaa' or col1 = 'bbb';←ORを利用。
改善例：INの改善例を参照。

悪い例：select * from demo_tbl where col1 like '%xyz';←後ろマッチングが遅い。頭マッチングは早い
改善方法？　そもそも、なんでこの業務が発生するの？設計・DB設計やデータの流れが業務に合わないではないでしょうか。
ここまで来たら、僕はLIKEで後ろマッチングよりも、SUBSTRを使ったら益しだ。
[/pre-dode]
上記のパフォーマンスが悪いSQLですが、実際の開発中によく使われていたSQLです。

また、そのたのSQL悪い例は下記のURLへご参考ください。
https://www.oracle.com/technetwork/jp/database/articles/tsushima/tsm09-1598259-ja.html

以上、メモを。





コメント 
♪ 当記事がお役に立ちましたらシェアして頂ければ嬉しいです。
0人
ツイート