■

いつもの調子でメンテナンス性重視なSQLを作ってました。
あっちゃこっちゃからﾃﾞｰﾀを引っ張ってきて
出力物はCSVというありがちな機能。

ﾃﾞｰﾀ件数と取得数期待値は100万件弱から数万件分とか、
10万件超から数千件分とかそんな状況。

母体数が若干多い気がするので、テンポラリテーブルを利用することにして。
メインとなるテーブルで一つ、
そのサブテーブルのデータを一つ。
ｺｰﾄﾞだけ入っているデータの元の値は各種マスタより、
テンポラリテーブルを一挙にアップデートすることで対処。
複雑怪奇なSQLやJOINタップリなSQLは好みではないので
極力使わないようにしているおいらがいる。

ちなみにOracleでPL/SQLを使っていたころは、
巨大なSQL文を1個作って一挙にSelectするよりも、
PL/SQLで一旦ワークテーブルにデータを作ってそこから検索する方式を採用していた。
だってそっちのが早いことが多いんだもん。
ﾌﾟﾛｸﾞﾗﾑ的にも、煩雑な全てはPL/SQLでやるので、Select文はめっちゃシンプル。
( ´∀｀)むふぅ

今回はPostgreSQL。ストアドプロシージャが使えることは知っているけれども、
書式の違いと特性はまだなーんにも知らないので後回しにしてみた。

さて。
ストアドも使わずに同じ事をPHPから行うべく、
SQLをつくり。動作確認をし。
単機能ごとの正当性も確認し。
いざ実行。

・・・・・・

帰ってきません。

一挙に数千件をやめ。
まずは3レコード限定とかで取得するように若干変更。
そして実行。

・・・キタ。

でも遅い。
テンポラリテーブル作成：数秒程度。
各種アップデート：数秒程度。
検索時間（数件分）：10ﾐﾘ未満。

数値は小さそうに見えなくも無いけれども。
ん〜しかしやっぱりなんか遅い。

検索も、1回当たりの時間は短くとも、回数をこなせば単位が変わる。
よし。試算だ。

今回、想定される回数は数千件に対して各17回。
仮に2000件としても2000×17＝34000回。
多いな。
時間はというと、34000×10ﾐﾘ秒＝340000ﾐﾘ秒。
340000ﾐﾘ秒＝340秒。
十分におせーじゃねーかよヽ(`Д´)ﾉ　ｳﾜｧｧﾝ

しかして実態はさらに違い。
6分以内に帰ってくるかと言うと30分経っても帰ってこない。
Webサーバのタイムアウトも絡んでいるのかしらと勘ぐらなくも無いけれど。
タイムアウトを解決しても根本的な解決にはならないので忘れてみた。
問題はクリックしてから30分経たないとダウンロードも始まらないシステムを使いたいユーザがいてるかということだ。
んなもんいてるわけがねぇ。

ってことで。

傾向と対策と検討。
解決策は2通りある。
(1) 検索SQLの発行回数を減らす努力をする。
(2) 一度忘れ去ったストアドプロシージャを使い解決の鍵とする。

メモリをたらふく利用し、巨大なSQLを作って一挙に物事の解決を試みるか、
DBサーバとWebサーバのデータ通信を最小化することでなんとかするか。
今回はPosgreSQLのストアドを使うことに後ろ髪を引かれつつ、
とりあえず巨大SQLを作ってみることにした。

結果。

レスポンスタイムが分から秒にかわりますた。
数千件＋数万件で帰ってこなかった状態から、20秒足らずで帰ってくるように。
すばらしい。もーこれでええやん。
そう思いながらも、仕様確定者に確認。
( ´∀｀)ﾉ＜50分が1分足らずになりましたが、どないでしょ？

1分ぐらいなら大ｼﾞｮﾌﾞちゃう？
という答えを引き出しメモっておくことで、責任はヤツの手に移った。
保身保身。φ（．．）