社内で業務システムを日常的に使う方であれば、検索画面のレスポンスの遅さにイライラした経験があるのではないでしょうか？
実際のところ、遅いレスポンスでよしと考える開発者はいません。頑張ってチューニングしたくてもできないから、そのような状況に陥ってしまうのです。
業務システムの仕組み
大抵の業務システムは、リレーショナルデータベース（RDB）と呼ばれるミドルウェアを使って、データを管理しています。業務データはすべてそこに格納されており、日々バックアップされています。RDBのイメージが湧かないのであれば、「システムが使うExcelブック」と考えていただければ良いかと思います。
どのRDBにも、「インデックス」と呼ばれる機能があります。これは、特定の列を常にソートされた状態に保っておく機能です。ソートされていると、検索が素早くできます。国語辞典が、５０音順に並んでいるのと同じ理屈です。
このインデックスは、１つのテーブル（Excelで例えるとシート）に複数貼ることができます。例えば、「５０音順」の国語辞典と、「品詞順（名詞・動詞など）」の国語辞典の２種類を持っていれば、２つのインデックスがある状態と言えます。この場合、業務システムの検索画面は、入力された検索条件に応じて、どちらの国語辞典を使うべきか選択する必要があります。
RDBの場合、この選ぶ作業は「オプティマイザ」と呼ばれるRDBの内部機能が担っています。利用者の検索パターンに合わせて、予めインデックスを用意しておくのは開発者の仕事ですが、使うべきインデックスを選択するのはオプティマイザの仕事です。オプティマイザは、利用者が入力した検索条件に基づいて、自動的に適切なインデックスを選択します。
前置きが長くなりましたが、ここまでの仕組みが分かっていれば、業務アプリの検索画面が遅い理由を理解できるようになります。
検索画面が遅い３つの理由
大別すると、遅い理由は３つあります。
1.使うインデックスを間違える
インデックスが多すぎて、オプティマイザが選択を誤ってしまうケースです。開発者としては、その検索で使うインデックスはこっちでしょ！と言いたくなる状態です。
更に悪いことに、オプティマイザはなまじ賢いので、インデックス選択の判断材料として、入力された検索条件の他に、格納データの内訳（統計）も使っています。その結果、同じ検索条件を入力しているのに、昨日と今日で使うインデックスが違うという事が起こります。利用者からすると、昨日までレスポンス早かったのに、今日いきなり遅くなった、と感じるわけです。
2.使えるインデックスがない
これは、文字列の部分一致検索をしようとするとよく起きます。普通のインデックスは、前方一致検索にしか対応していません。部分一致検索する為には、フルテキストインデックス（転置インデックス）と呼ばれる特殊なインデックスが必要になるのですが、普通のインデックスよりも運用が大変なので、採用しないケースも多いのです。
3.インデックスはあるけど役に立たない
国語辞典で例えるなら、「あ」から始まる単語が99%で、それ以外が1％といった状態です。データがある程度均等にばらけていないと、インデックスを使っても早い検索はできません。オプティマイザは、使えないと判断したインデックスは、あっても使いません。
解決策は？
根本的に解決しようとするなら、テーブル設計を見直すことが一番です。
ただ残念なことに、このような性能問題は開発終盤に発覚することが殆どなので、そこまで遡って見直しする時間が残されていないケースが殆どなのです。（家を建てることに例えるなら、完成間近に間取りを変えるようなものです）
じゃあ、開発者としてこの問題にどう立ち向かうべきなのか？長年の経験の中で、私が思い描いている解決案がありますので、次回のブログで公開したいと思います。