現場で作っている去年リリースしたサービスが結構順調で、

順当に顧客数が増えている様子。

ありがたい限り。

 

それに伴って、

現在のサービスの一覧画面のパフォーマンス改善

こちらをそろそろ考えないといけないのかなと思い。。

（データ数的にまだ全然大丈夫だけど、将来いつかやらないといけないこと）

 

実は今のバックエンドの検索SQL

遅くなる３要因を全て踏んでしまっている状況。。（すみません、実装者は私です。）

１）limit offsetでページングをしている

２）部分一致検索をしている

３）ソートしている

 

まず１）のlimit offset問題

これは最近知ったのだけれど「キーセットページング」なるもので結構解消するらしい。

offsetの何が問題かというと、「使いもしないのに大量の捨てデータを最初から走破する必要がある」という点。

これはページング番号の後ろになればなるほど大きなパフォーマンス低下につながる。

 

そこでキーセットページング

IDなり日付データなり、インデックスを張って対象の行までジャンプ！

そこからlimit行数分を取得するという代物で、

offsetと異なり無駄なレコードの走破が不要となる。

 

ただしこれ、

一覧画面のページングで数ページ飛ばしてジャンプ！みたいな機能には使えない。

なぜならキーセットなので、「次へ」はできるけど「５ページ先へ」みたいな場合、

そのページ分キーセットで検索を繰り返さないといけない。非効率。

 

しかし例えばページ番号の表示ではなく

スクロールによる追加読み込みの画面だったら正気はある。

実質「次へ」しかないわけだから。

ちなみにうちのサービスの一覧画面はスクロール型なので、キーセットページングが使える。やったぜ！