OracleからAurora(MySQL)への移行（その５）

OracleとMySQLではソート順にも差の出る部分があります。
NULLを含む列のソートです。
“ORDER BY <COLUMN_NAME> ASC”でデータをソートした場合、OracleではNULLが最後にMySQLでは先頭に表示されます。
プロジェクトの方針ということで、”ORDER BY IFNULL(<COLUMN_NAME>, ‘1’), <COLUMN_NAME> ASC”などとして対応しました。
が、ホンネを言うと、「DBのエンジンが違うものになるのだから、コレ（Oracle/MySQLのソート結果の差異）くらい先にネゴってお客さんからAgreeもらっといてよ」というところです。
NULL関係はソート順、関数の挙動などで度々悩まされることがあるので、実機による検証を強くオススメします。
上記のIFNULL関数での対応はプロジェクト方針として採用されたコーディング技法でしたが、ググったところこんな記事も出てきましたので、ご参考まで。（※実機検証してくださいねｗ）

3.6.性能関連の機能の有無

ここでは性能関連で、OracleにあってMySQLに無いために対応に苦労した機能について記述します。

HASH JOINが無い

性能関連で一番苦労したのがコレですね。
OracleにはHASH JOINがあるので、大量データのテーブル同士を結合しても割と難なくこなせるのですが、MySQLにはこの機能が無いために、大量データのテーブル同士を結合すると動かなくなります。
主な対応としては、SQLをあの手この手で組み替えて結合前にデータを絞り込む事で、どうにか動くようになりました。

述語のプッシュが無い

もの凄くざっくり話すと、OracleはWHERE句の絞り込み条件で他のテーブルにも適用できるものがあると、オプティマイザが良い感じに使いまわしてくれます。（詳細についてはコチラでどうぞ。）
この機能のお陰で、OracleのSQLはデータの絞り込み条件をシンプルに記述することができました。
MySQLではこの機能が無いために、各テーブル用にデータの絞り込み条件を一々書く必要があります。
お陰でSQLが異様に長くなって読みにくいったらありゃしない。。。(；´Д｀)

私見ですが、関数や機能の有無で四苦八苦するということは、元々のデータ設計およびテーブル設計がよろしくないのが原因です。
汎用機からの焼き直しシステムであれば、RDBMSの特性を活かしたデータ設計で再設計をすること。
データ設計の際に、きちんと正規化すること。
シンプルなデータ取得ができるようにテーブル設計をすること。
SELECTする際に一々関数で計算する必要があるならば、計算結果を別カラムで登録しておくこと。
等々、設計段階でちょっとした気を利かせておけば、性能劣化などはそうそう起こらないと考えています。

今回はここまで。