データが増えて一覧が遅い。DB設計で先に見る3か所

記事

IT・テクノロジー

2026/09/07 03:40

公開したときは一瞬で開いた一覧画面が、半年たつと数秒待つようになる。注文の一覧、会員の一覧、予約の一覧。データが数百件のうちは何も起きず、数万件を超えたあたりで急に重くなります。自分で作ったときも、人に頼んで作ってもらったときも、つまずくのは同じところです。

重くなると、まず「サーバーを強くする」「作った人の腕が足りなかった」と考えがちです。でも原因の多くは腕ではなく、作り始める前に決めていなかったことにあります。一覧画面は、データが少ないうちはどんな作り方でも速く見えるので、決めていない部分が後から出てくるのです。

先に見る場所は3か所に絞れます。

1. 一覧に出す項目を先に決めているか

一覧で本当に見せる項目は、名前・日付・状態など数個です。ところが設計を決めずに作ると、1行ごとに関係する表を全部読み込む形になりがちです。100行の一覧を出すために、裏で101回の問い合わせが走る形です。よく知られたつまずき方ですが、件数が少ないうちは気づけません。

自分で作った有料1対1通話サービスは、Prismaのモデルが23個あります。予約の一覧をひとつ出すにも、予約・利用者・決済・通話の記録と、複数の表をまたぎます。表が増えるほど「この画面ではどの表の、どの列だけを使うか」を先に書き出しておかないと、後から重くなる形になりやすいと実感しています。

2. 絞り込みと並び替えに使う列に索引があるか

一覧画面には「新しい順に並べる」「未対応だけ見る」「日付で絞る」がほぼ付きます。この並び替えや絞り込みに使う列に索引（本の目次にあたるもの）が無いと、データベースは全件を頭から読みます。1万件なら我慢できても、100万件では待てません。

見るべきなのは、索引があるかどうかより「画面で使う条件と、索引の列が一致しているか」です。作り始める前に、一覧画面ごとに「何で絞るか」「何で並べるか」を一行ずつ書き出すと、必要な索引は自然に決まります。

3. 件数の数え方とページ送りの形

一覧の下に「全12,345件」「1/247ページ」と出す作りは多いです。ただ、この件数を出すために毎回全件を数えていると、件数が増えるほど、一覧そのものより数える方が重くなります。

ページ送りも同じです。「先頭から3万件飛ばして20件」という取り方は、飛ばす件数が増えるほど遅くなります。「前のページの最後の日付より古いものを20件」という取り方に変えると、何ページ目でも同じ速さで返ります。どちらの形にするかは、後から変えると画面の作り直しになるので、最初に決めておく方が安く済みます。