System iを愛するすべての人のためのコミュニティサイト

前回、SELECT/OMIT の論理ファイルが存在するとそれだけで単純な SQL でも旧式のデータベースエンジンに制御がわたってしまうので
あまりパフォーマンスの観点からは好ましくないことが多い、というお話をしました。

今回は、この SELECT/OMIT の論理ファイルというもの自体も実はあまり効率のいいものではない、というお話です。

SQL の FROM 句に SELECT/OMIT の論理ファイルを指定するのはおすすめしません。システム資源を浪費したいのならいいですけれども!?

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 に指定するのは止めた方がいいですよ。