■ LEFT JOIN が分かっていない！
症状：
Oracle から MySQL(Amazon RDS for MySQL)に移行したら、検索が重くなって使い物にならなくなった。
診断時間：
1時間
原因：
LEFT JOIN が分かっていないため、論理削除しているマスタの結合をすべてサブクエリで行っていた。
例)
SELECT
*
FROM
売上データ u
LEFT OUTER JOIN
(SELECT * FROM 顧客マスタ WHERE 削除フラグ <> 1) c
ON u.顧客ID = c.ID;
この場合、顧客マスタのインデックスは全く利用できません。
Oracleでは、削除フラグ <> 1 となる顧客マスタの抽出結果をハッシュテーブルに格納してから結合する(ハッシュジョイン)となり、ある程度のスピードが出るのですが、MySQLではハッシュジョインがサポートされていないため、非常に遅くなっていました。
対応策：
SQLの基本構文の理解ができていない人が、設計・コーディングを行っていたため、システムの全面に同様の問題が存在した。
対応が取れる時間は限られているため、特に問題になっているSQLをピックアップして以下の様に修正を行った。
例)
SELECT
*
FROM
売上データ u
LEFT OUTER JOIN
(SELECT * FROM 顧客マスタ WHERE 削除フラグ <> 1) c
ON u.顧客ID = c.ID;
↓ 修正
SELECT
*
FROM
売上データ u
LEFT OUTER JOIN 顧客マスタ c
ON u.顧客ID = c.ID
AND 1 <> c.削除フラグ ;
コメント：
SQLの基本構文の理解ができていない人が、設計・コーディングを行っていたため、他にも問題は多数あります。
手の施しようがないですが、サブクエリをなくすだけで実用に耐えるパフォーマンスにはなりました。
しかし、最初からサブクエリをなくしていればコーディング量も格段に減っていました。
10億円規模のプロジェクトの共通仕様に「サブクエリにしなさい」と書かれていたこともあります。
そのプロジェクトを私が見たときは、既に納期遅れで、何十人もの技術者が泊まり込んで、入院する人が何人も出ている状態でした。
(私一人ではどうにもできない状況だったため、手は出しませんでしたが……)
同様の間違いをしているプロジェクトは今でも多数あります。
それを指揮してきたSIerは、20年前後、間違ったまま続けているということです。
そんなSIerを正すよりも、開発の内製化を行った方が効率的なのです。
