社内SQLアンチパターン輪読会の資料、第17章スパゲッティクエリです。

1. SQLアンチパターン
～スパゲッティクエリ～
CB部ADチーム
板橋正之
2014/06/17

2. ある事柄を説明するために
必要以上に多くの実体を
仮定するべきではない
～オッカムのウィリアム

3. オッカムの剃刀

4. オッカムのウィリアムは
オッカム村生まれのウィリアムさん
ヴィンチ村生まれの
レオナルドさんと同じ意味

5. 目的：
SQLクエリの数を減らす

6. アンチパターン:
複雑な問題をワンステップで
解決しようとする

7. 解決策：
分割統治を行う

8. シンプル・イズ・ベスト

9. SQLコードを簡単に

12. もうちょっと説明します。

13. SQLのクエリも
プログラミングと一緒

14. 1つのメソッドで多くの処理
→Bad!!
1つのSQLで複雑な問い合わせ
→Bad!!

15. 複雑なクエリは
クエリの修正、変更、デバッグも
複雑に

16. クエリの数が減れば
パフォーマンスが上がる
→間違い

17. 必ずしもパフォーマンスは
上がらないし、
逆に複雑すぎて最適化が
働かない可能性も

18. パフォーマンスチューニングも
難しい。
複雑なメソッドはコードレビューが
難しいのと一緒。

19. 複雑すぎて自分で何を
やっているのかわからなくなる。
1週間後にそのSQLクエリ
読み解けますか？

20. 意図に反した結果

21. 以下の2つのテーブルからproduct_idが1の製品のバグが完了(FIXED) と
未修正（OPEN）の件数を問い合わせたい。
BugsProducts Bugs

22. SELECT p.product_id, COUNT(f.bug_id) AS count_fixed , COUNT(o.bug_id) AS count_open
FROM BugsProducts p
INNER JOIN Bugs f
ON (p.bug_id = f.bug_id AND f.status = 'FIXED')
INNER JOIN BugsProducts p2 USING (product_id)
INNER JOIN Bugs o
ON (p2.bug_id = o.bug_id AND o.status = 'OPEN')
WHERE p.product_id = 1
GROUP BY p.product_id;

23. 想定では以下のような結果をもとに件数が集計できるはず。
FIXEDの結果 OPENの結果
件数集計

24. 現実
FIXEDの結果 OPENの結果
件数集計

25. • デカルト積（直積）
–2つのテーブルの間に関連を制限
する条件を持たないときに生まれ
る。
–この制限がないと1つのテーブル
の各行が、もう1つのテーブルのす
べての行と組合せになってしまう。

26. 両方のテーブルの行のすべての組み合わせが
取得されます。

27. SELECT p.product_id, COUNT(f.bug_id) AS count_fixed , COUNT(o.bug_id) AS count_open
FROM BugsProducts p
INNER JOIN Bugs f
ON (p.bug_id = f.bug_id AND f.status = 'FIXED')
INNER JOIN BugsProducts p2 USING (product_id)
INNER JOIN Bugs o
ON (p2.bug_id = o.bug_id AND o.status = 'OPEN')
WHERE p.product_id = 1
GROUP BY p.product_id;
①
②
①でstatusが'FIXED'
②でstatusが'OPEN'を求め
USINGで両者を関連付けているように見えて関連付けられていないため
①と②の2つの間に関連を制限する条件が持たないのでデカルト積が生じている。

29. アンチパターンの見つけ方

30. 「ありえないくらいの行数が
返ってきてるんですけどー」

31. うん、直積（デカルト積）されて
結果が返ってきてるね。
複雑すぎてちゃんと結合条件
書けていないんじゃない？

32. 「この複雑なSQLクエリを
書くのに、丸1日かかった
（ドヤァ！）」

33. そんなに時間かけるんだったら
もっと簡単にできる
アプローチ探したら？

34. 「このレポート出力には、
もう何も追加できない。
SQLクエリを書き直すのは
手間がかかりすぎる！」

35. お前、
客先でも同じこと言えんのか？

36. 「このクエリに、
もう1つDISTINCTを
追加してみよう（提案）」

37. 直積で返ってくるのを集約して
ごまかしているだけだろ？
見た目は合うけど、
ソートや重複排除で
パフォーマンス最悪だよ？

38. アンチパターンを用いても
よい場合

39. プログラミングフレームワークや
ビジュアルコンポーネントライブラリ、
BIツール（安い）とか使ってる場合は
（仕方がないので）使ってもいいよ。

40. でも、複雑、難しいことを
無理やりやるより
別アプローチ探す方が
建設的だよ。

41. 後、複数のクエリ結果をまとめて
ソートするような場合は
DBで行う方が効率的な場合が
多いかも。

42. 解決策

43. ワンステップずつ

44. SELECT p.product_id, COUNT(f.bug_id) AS count_fixed
FROM BugsProducts p
LEFT OUTER JOIN Bugs f
ON (p.bug_id = f.bug_id AND f.status = 'FIXED')
WHERE p.product_id = 1
GROUP BY p.product_id;
SELECT p.product_id, COUNT(o.bug_id) AS count_open
FROM BugsProducts p
LEFT OUTER JOIN Bugs o
ON (p.bug_id = o.bug_id AND o.status = 'OPEN')
WHERE p.product_id = 1
GROUP BY p.product_id;
SELECT p.product_id, COUNT(f.bug_id) AS count_fixed , COUNT(o.bug_id) AS count_open
FROM BugsProducts p
INNER JOIN Bugs f
ON (p.bug_id = f.bug_id AND f.status = 'FIXED')
INNER JOIN BugsProducts p2 USING (product_id)
INNER JOIN Bugs o
ON (p2.bug_id = o.bug_id AND o.status = 'OPEN')
WHERE p.product_id = 1
GROUP BY p.product_id;

45. • 望まないデカルト積が生じない。
• 修正・変更が簡単。
• 一般的に単純なクエリの方がス
ムーズかつ確実に実行される。
• コードレビューも容易。

47. UNIONを用いる

48. (SELECT p.product_id, 'FIXED' AS status, COUNT(f.bug_id) AS bug_count
FROM BugsProducts p
LEFT OUTER JOIN Bugs f
ON (p.bug_id = f.bug_id AND f.status = 'FIXED')
WHERE p.product_id = 1
GROUP BY p.product_id)
UNION
(SELECT p.product_id, 'OPEN' AS status, COUNT(o.bug_id) AS bug_count
FROM BugsProducts p
LEFT OUTER JOIN Bugs o
ON (p.bug_id = o.bug_id AND o.status = 'OPEN')
WHERE p.product_id = 1
GROUP BY p.product_id)
ORDER BY bug_count DESC;
SELECT p.product_id, COUNT(f.bug_id) AS count_fixed , COUNT(o.bug_id) AS count_open
FROM BugsProducts p
INNER JOIN Bugs f
ON (p.bug_id = f.bug_id AND f.status = 'FIXED')
INNER JOIN BugsProducts p2 USING (product_id)
INNER JOIN Bugs o
ON (p2.bug_id = o.bug_id AND o.status = 'OPEN')
WHERE p.product_id = 1
GROUP BY p.product_id;

49. • 2つのサブクエリの結果を合わせ
たもの

51. CASE式とSUM関数を
組み合わせる

52. SELECT p.product_id,
SUM(CASE b.status WHEN 'FIXED' THEN 1 ELSE 0 END) AS count_fixed,
SUM(CASE b.status WHEN 'OPEN' THEN 1 ELSE 0 END) AS count_open
FROM BugsProducts p
INNER JOIN Bugs b USING (bug_id)
WHERE p.product_id = 1
GROUP BY p.product_id;
SELECT p.product_id, COUNT(f.bug_id) AS count_fixed , COUNT(o.bug_id) AS count_open
FROM BugsProducts p
INNER JOIN Bugs f
ON (p.bug_id = f.bug_id AND f.status = 'FIXED')
INNER JOIN BugsProducts p2 USING (product_id)
INNER JOIN Bugs o
ON (p2.bug_id = o.bug_id AND o.status = 'OPEN')
WHERE p.product_id = 1
GROUP BY p.product_id;

54. SELECT文の副問い合わせを
用いる
（SQLアンチパターンには
載っていない方法）

55. SELECT t1.product_id, count_fixed, count_open
FROM
(
SELECT p.product_id, COUNT(f.bug_id) AS count_fixed
FROM BugsProducts p INNER JOIN Bugs f
ON (p.bug_id = f.bug_id AND f.status = 'FIXED')
WHERE p.product_id = 1
GROUP BY p.product_id
) t1,
(
SELECT p2.product_id, COUNT(o.bug_id) AS count_open
FROM BugsProducts p2 INNER JOIN Bugs o
ON (p2.bug_id = o.bug_id AND o.status = 'OPEN')
WHERE p2.product_id = 1
GROUP BY p2.product_id
) t2
WHERE t1.product_id = t2.product_id;
SELECT p.product_id, COUNT(f.bug_id) AS count_fixed , COUNT(o.bug_id) AS count_open
FROM BugsProducts p
INNER JOIN Bugs f
ON (p.bug_id = f.bug_id AND f.status = 'FIXED')
INNER JOIN BugsProducts p2 USING (product_id)
INNER JOIN Bugs o
ON (p2.bug_id = o.bug_id AND o.status = 'OPEN')
WHERE p.product_id = 1
GROUP BY p.product_id;

57. • FROM句の中にSELECT文を記
述して一時テーブルを作成して
関連を制限する条件で結合する。
• FROM句の中のSELECT文は実
行時にメモリ上等に生成され、イ
ンデックスなどがないため、大き
な結果が返る副問い合わせでは
注意が必要。

58. 求められている問題を
解決する

59. 誰も1つのレポートで
結果くれとは言ってないよ？

60. SQLを用いたSQLの自動的な記述

61. 複雑なSQLクエリを分割すると
似たようなクエリをいくつも作成す
ることがあります。

62. よく似たクエリをいくつも書くのは
煩わしいので
シェルやマクロ、場合によっては
SQLクエリ自体でSQLクエリを
生成しましょう。

63. 最新の日付で更新する

64. SELECT CONCAT(
'UPDATE Inventory SET last_used = ''', MAX(u.usage_date), '''',
' WHERE inventory_id = ', u.inventory_id, ';') AS update_statement
FROM ComputerUsage u
GROUP BY u.inventory_id;
出力された結果をコピペして
SQL文として実行する。

65. まとめ

66. SQLでは、1行のコードで複雑な問
題を解決できると思える場合があ
ります。
しかし、状況に応じてクエリを分割
することも検討するようにしましょう。

67. デカルト積（直積）がどうこうとかで
はなくて、まったく同じ結果セットを
生む2つのクエリを選択できる場合
は、単純なクエリを選ぶべきであ
るということ。

68. また、クエリの結果セット以前に目
的を達成するためには単純な方
法が優れていることがあるというこ
とです。

69. 以上、
ご清聴ありがとうございました。