目次
概要
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ファースト開発を！
参考
その他
