プログラミングマガジン

プログラミングを中心にIT技術をできるだけわかりやすくまとめます。

  • ホーム
  • データベース
  • 【データベース】「ORDER BY句」の仕組みについて(インデックスの有効活用)
 
 
     
  • サーバー言語  
    • Python
    • Ruby
    • PHP
    • SQL
  •  
  • インフラ  
       
    • AWS
    •  
    • 基本
    • Git
  • Web
       
    • Web開発
    • JavaScript
    • Vue.js
    • React
  •  
  • 設計  
       
    • 実装設計
    • DB設計
  • 問い合わせ
  

【データベース】「ORDER BY句」の仕組みについて(インデックスの有効活用)

10.03

  • miyabisan2
  • コメントを書く

この記事は2分で読めます

ORDER BYの仕組み

全てのデータを取り出してから、ORDER BYで並び替えて、最後にLIMITで必要なデータを取り出します。

データを取り出してからバラバラの大量のデータを並び替えるため基本的にソートはかなり高コストな処理になります。実際のデータが大きくなればなるほどコストは増大していきます。

対処法

事前にWHERE句を使って対象を絞り込む

事前に絞り込めばORDER BY句のパフォーマンスはかなり上がります。さらにWHERE句でインデックスを使えればさらにパフォーマンスが上がるので尚良いです。(「WHERE句狙いのインデックス」と言います。)

「ORDER BY句狙いのインデックス」を使う。

WHERE句にインデックスを適用することが必ずしも最適ではないです。(カーディナリティが低く、データが偏っている場合などはWHERE句にインデックスを使っても効果は薄い。)

PostgreSQLとMySQLの標準的なインデックスの実装であるBTree Indexはデータをソート済みの状態で保存している。対象のソート結果とインデックスが同じであればインデックスから値を取り出せば良いという考え方です。(ソートの処理をすることなく、インデックスから該当データを順番に取り出すだけで済む)

なので、WHERE句ではなく、ORDER BY句に対してインデックスを使うことで効果が出る場合があります。

ORDER BY句インデックスの強み

  • ソート処理が不要になる。
  • 評価数がLIMITの件数に達した時点で結果を返せる。

どちらの対策を取れば良いかの判断材料

「WHERE句狙いのインデックス」が良いか「ORDER BY句狙いのインデックス」が良いかは、中に入っているデータによって変わります。そのためには「実行計画」をよく見ることが重要です。定期的に実行計画を叩いて最適な設計手法を選択できるように精進しましょう。

オプティマイザは今の情報しかわからず未来にどんなデータが入っているかはわからないので、DB専門担当ではなくてもバックエンドエンジニアは日々実行計画を監視していくことが重要です。

最近は、MySQL Workbenchや、pgAdmin4など実行計画をグラフィカルに表示してくれるツールも充実してきています。既存のアプリケーションでも新たな発見があってSQLの見直しで大幅にパフォーマンスが向上するということもあるかもしれません。(特に今回ご紹介したソート処理は大きくパフォーマンスを改善できます。)

スポンサーリンク
  • 2021 10.03
  • miyabisan2
  • コメントを書く
  • データベース
  • Tweets Twitter
  • このエントリーをはてなブックマークに追加
  • LINEで送る

関連記事

  1. 2018 04.29

    【データベース設計】ハードウェアのサイジング(容量と性能)を決める。(物理設計)

  2. 2018 04.28

    【データベース】主キー、ユニークキーについて

  3. 2020 12.12

    【データベース】バッチ処理の排他制御

  4. 2020 08.13

    【DBスペシャリスト】「生産管理」業務、「発注・仕入・支払」業務

  5. 2020 08.12

    【DBスペシャリスト】スーパータイプ、サブタイプ

  6. 2020 11.02

    【Ruby on Rails】「Redis」の基本、Railsへの導入

  • コメント ( 0 )
  • トラックバック ( 0 )
  1. この記事へのコメントはありません。

  1. この記事へのトラックバックはありません。

返信をキャンセルする。

【データベース】テーブル設計:「削除フラグの闇」につい…

【設計】RDBの基本思想(ソートが苦手)、大きなデータ…

RETURN TOP

著者プロフィール

エンジニア歴10年で過去に業務系、Webデザイン、インフラ系なども経験あります。現在はWeb系でフロントエンド開発中心です。

詳細なプロフィールはこちら

スポンサーリンク

カテゴリー

  • Android
  • API
  • AWS
  • C++
  • CSS
  • C言語
  • DDD
  • DevOps
  • Django
  • Docker
  • Git
  • GitLab
  • GraphQL
  • Hasura
  • Java
  • JavaScript
  • Kubernetes
  • Laravel
  • linux
  • MySQL
  • Next.js
  • nginx
  • Node.js
  • NoSQL
  • Nuxt.js
  • Oracle
  • PHP
  • Python
  • React
  • Redux
  • Rspec
  • Ruby
  • Ruby on Rails
  • Sass
  • Spring Framework
  • SQL
  • TypeScript
  • Unity
  • Vue.js
  • WebRTC
  • Webサービス開発
  • Webデザイン
  • Web技術
  • インフラ
  • オブジェクト指向
  • システム開発
  • セキュリティ
  • その他
  • データベース
  • デザインパターン
  • テスト
  • ネットワーク
  • プログラミング全般
  • マイクロサービス
  • マイクロソフト系技術
  • マルチメディア
  • リファクタリング
  • 副業
  • 未分類
  • 業務知識
  • 設計
  • 関数型言語
RETURN TOP

Copyright ©  プログラミングマガジン | プライバシーポリシー