227万件のレコードをSQLで読むというのはかなり乱暴に思えます。
SQLでのレコード抽出はすべてのレコードを読んでから
抽出するので当然パフォーマンスは良くありません。
それとSQLは索引部分をすべてCPUメモリの中に取込んで
しまうので大量のメモリを消費します。
その　SQL　も　227万件のレコードを全部読んでから
レコードを抽出しているのです。

ただしメモリ消費量が　100%　近くなったとしても
IBM　i　自体には何の問題もありませんが
当然、他の業務はかなり遅くなってしまい
エンド・ユーザーからはクレームの嵐になります。

Windows　PCに比べて　IBM　i　のCPU容量は小さいとは思いませんか?
これは　IBM　i　がレコード単位のアクセスが基本であるので
1レコードを読取るメモリがあれば十分であるのに対して
Windows　のアーキテクチャーはプログラムがファイルを
読むのはファイル全体を読んですべてメモリに入れてから
処理するからです。
つまり　Windows適用プログラムはファイル全体を読み込んで
しまわないと処理できないのです。
Windwosはストリーム・ファイルしか扱えないので
こんなことになってしまっています。
これが　Windows　がビジネス・ユースに向いていない原因です。

つまり　100MB　の容量のファイルを読むには　CPUが　100MB　を
必要となってしまいます。
これに対して　IBM　i　は　1レコード分しか読まないので
例えば　1レコードはせいぜい　1024バイトくらいしか必要ないのです。

ところが　SQL　となると　IBM　i　でも話は別で
Windows　と同じことが起こります。
つまりすべてのレコードを読んでメモリに入れる必要があるので
メモリを大量消費してしまいます。

ところが227万件あるデータ・ベースでもキーつきのファイルであれば
RPG　で　CHAIN　すれば　0.01秒もかかりません。

もちろんメモリの消費も起こりません。
これは対象データ・ベースが　1000万件であっても同じです。
レコードは一瞬で抜き出されます。

長々と書いてしまいましたが　SQL　は大量データ・ベースのアクセスには
全く向いていませんし大量データ・ベースに　SQL　でフクセスするのは
不適切です。

たまに　CHAIN　を知らない開発者が無理やりなんでもSQLで
アクセスしているのを見かけますが　IBM　i　にはせっかく
レコード・レベルのアクセスとして　CHAIN　があるのですから
是非利用してください。
大量データ・ベースに対しては苦手であってもSQLはやめましょう。

ご参考までに　COBOL　には　CHAINはありません。