IT系/SQL/性能改善

Last-modified: 2020-04-13 (月) 02:13:31

目次

概要

SQLの性能改善に関する内容をまとめる。

SQLとは

SQLは「集合志向」言語

役割分担を適切に行う

SQLアンチパターン：ぐるぐる系

ぐるぐる系＝アプリ側でSQL発行ループを行うこと。

＜デメリット＞
以下の点で負荷が重くなる原因となり、性能悪化を引き起こす。

  • SQL文の送信・パース・コンパイル回数
  • DBサーバとAPサーバ間のデータ転送量
  • AP側の実行命令数

手続き型言語とSQLの設計思想の違い

＜手続き型言語（Java、C#など）＞

  • 実行順序を記述する
  • どんなデータでも繰り返し処理をかけるようにシンプルなループ構文を実装

＜SQL＞

  • 簡易指定で同じ操作を一括適用する
  • ループ構文を使わなくても繰り返し処理ができるようにデータを定式化（一定のパターン：表形式等）

SQLの得意とするデータ操作はSQLにやらせる

DBMSに蓄積されたデータを操作するための言語がSQL。
データ操作が得意なのは当然。
それでもSQLの使用を最低限に留めようとする開発現場は多い。その背景は何か。

＜背景など＞
SQLへの無理解が基本的に背景にある？

  • 手続き型言語を先に習得した技術者は、設計思想の異なるSQLを忌避する傾向にある
  • ORMのようにSQLを隠ぺいするライブラリの流行：SQLを書かずにすべてを手続き型言語で閉じるようにしたがる開発者も
  • 複雑なSQLを使用したプロジェクトが炎上し、問題点にSQLがやり玉に挙げられた
  • SQLでは複雑なロジックを組むことはできない、アプリ側で実装すべきという思い込み

表形式のデータ操作イメージ

結合条件と抽出条件

ON句・WHERE句

結合条件と抽出条件を区別する

SQLで複雑なロジックを組めるか

CASE式とパラメータテーブル

INとEXISTSの違い

選択性の高低による使い分け

INとEXISTSの処理の流れ

相関サブクエリ

データベースがSQLを処理する流れ

「ループ」が引き起こす3つの問題

DBとAPの役割分担

実行計画を確認する

インデックスが効くときと効かないときの違い

JOINのアルゴリズムを理解する

3種類のJOINアルゴリズム

「スケールアウトしにくいからJOIN禁止」という間違った考え方

JOIN禁止はかえって負荷を増やす

データベースで集計するほうが低負荷になる

SQLで集計をすると処理を分散できないか

DBで集計したほうが低負荷になる理由とは

負荷はピークではなく面積で考える

NoSQL

RDBが登場した理由

NoSQLが登場した理由

RDBとNoSQLの使い分け

SQL動的組み立ての回避

SQLの動的組み立てはSQLインジェクションに弱い

パラメータクエリでインジェクション回避

EAVアンチパターン

EAVを使いたくなる3パターン

RDBの得意分野を正しく理解して使おう

SQLのための仕様書は必要か

書類を増やしたからといって役に立つとは限らない

SQLは「要求」レベルを記述する言語

SQL自体が仕様書のようなもの

O/Rマッパーを使うべきか・使わないべきか

N＋1問題とは

インピーダンス・ミスマッチ

O/Rマッパーを使っていいとき・悪いとき

テーブル設計の変更で大きな手戻りを発生させない方法

「テーブル設計は後まわし」の真意とは？

DBアクセスをAPI化する「APIファースト開発」

DB担当とAP担当を分けてAPIファースト開発を！

参考

その他