SQLでこのSELECT/OMIT の論理ファイルを直接アクセスしてみましょう。（今回も V5R4 でのシステムでの実行結果になります）
SELECT * FROM SOLF;
SELECT/OMIT の論理ファイルが索引として使われます。
実行時間は ↓ のようになっています。
実行時間は 29(13+16) ミリ秒でした。
では、LF と SQL とで比較してみましょうか。
LF に存在する SELECT/OMIT の条件をそのまま WHERE 句に移した SQL を実行してみましょう。
SELECT * FROM JUMIDP WHERE JHKING > 100000;
実行結果です。
データベースエンジンは CQE のままなのですが、SELECT/OMIT の論理ファイルはインデックスとしては使用されていません。
（これもよく考えてみれば？ですよね。効率のよいインデックスなら使われるはずですね?!）
実行時間を見てみましょう。
インデックスは使われずテーブルスキャンになっているのにもかかわらず 16(3+約13) ミリ秒と速くなっているのがわかります。
同じCQEで処理されている、という条件なのに、SELECT/OMITの論理ファイルを使用するよりテーブルスキャンして条件選択する方が倍近く速いんですね。
では、SQEで実行させるとどうなるでしょうか。
SELECT * FROM JUMIDP WHERE JHKING > 100000;
実行結果は ↓ のようになっています。
やはりテーブルスキャンになりますが、全部で 9 ミリ秒と CQE の同一 SQL よりさらに速くなりました。
こうやってちょっとした実験をしてみただけでも、SELECT/OMITの論理ファイルが一番パフォーマンスが悪くなっています。
（29 (S/O LF 直接アクセス) → 16 (CQE) → 9 (SQE) とそれぞれ倍近くなっていますね）
CQE で実行させてさえ SELECT/OMIT の論理ファイルの方がパフォーマンスが悪い、というのはけっこう衝撃的ではありませんか?!
SELECT/OMIT の論理ファイルがあるだけで、
- SQL が遅くなってしまう、
- その論理ファイルのアクセス効率もよくない、
- さらに元テーブル更新時の負荷がかかってしまう、
と正直あまりいいことはありません。。
ときどき SELECT/OMIT の論理ファイルのパフォーマンスについて”信仰”をお持ちの方がいらっしゃいますが、
今や SQL の方がパフォーマンスがいい時代になっているのは確かです。
SQL より論理ファイルの方が効率がいい、とかそういうことは全然ありませんので、ぜひ改めてのご認識を。
少なくとも SELECT/OMIT の論理ファイルを直接 SQL に指定するのは止めた方がいいですよ。