絞り込み条件を変更する
検索条件を絞り込む

すべてのブログから「#パフォーマンス改善」タグの検索結果

1 件中 1 - 1 件表示
カバー画像

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

公開したときは一瞬で開いた一覧画面が、半年たつと数秒待つようになる。注文の一覧、会員の一覧、予約の一覧。データが数百件のうちは何も起きず、数万件を超えたあたりで急に重くなります。自分で作ったときも、人に頼んで作ってもらったときも、つまずくのは同じところです。重くなると、まず「サーバーを強くする」「作った人の腕が足りなかった」と考えがちです。でも原因の多くは腕ではなく、作り始める前に決めていなかったことにあります。一覧画面は、データが少ないうちはどんな作り方でも速く見えるので、決めていない部分が後から出てくるのです。先に見る場所は3か所に絞れます。1. 一覧に出す項目を先に決めているか一覧で本当に見せる項目は、名前・日付・状態など数個です。ところが設計を決めずに作ると、1行ごとに関係する表を全部読み込む形になりがちです。100行の一覧を出すために、裏で101回の問い合わせが走る形です。よく知られたつまずき方ですが、件数が少ないうちは気づけません。自分で作った有料1対1通話サービスは、Prismaのモデルが23個あります。予約の一覧をひとつ出すにも、予約・利用者・決済・通話の記録と、複数の表をまたぎます。表が増えるほど「この画面ではどの表の、どの列だけを使うか」を先に書き出しておかないと、後から重くなる形になりやすいと実感しています。2. 絞り込みと並び替えに使う列に索引があるか一覧画面には「新しい順に並べる」「未対応だけ見る」「日付で絞る」がほぼ付きます。この並び替えや絞り込みに使う列に索引(本の目次にあたるもの)が無いと、データベースは全件を頭から読みます。1万件なら我慢できて
0
1 件中 1 - 1