はじめに
データベース管理者として日々多くのクエリをレビューしていますが、意外にも多くのエンジニアが「演算子の優先順位」を軽視していることに気づかされます。特に複雑なWHERE句やJOIN条件において、意図した通りのフィルタリングが行われず、結果としてデータの整合性が損なわれたり、インデックスが効果的に機能せずパフォーマンスが劇的に低下したりするケースは後を絶ちません。今回は、SQLにおける演算子の優先順位を再確認し、実務で安全かつ高速なクエリを書くための指針を解説します。
演算子の優先順位とは何か
SQLにおいて、一つの式の中に複数の演算子が含まれる場合、どの演算子が先に評価されるかを決めるのが「優先順位」です。プログラミング言語の数学的演算と同様に、SQLにも厳格なルールが存在します。しかし、SQLは数学の四則演算以上に複雑な要素（論理演算子、比較演算子、ビット演算子など）が絡み合うため、直感だけでクエリを書くと予期せぬ挙動を招きます。
多くのデータベースエンジン（MySQL, PostgreSQL, Oracle, SQL Serverなど）で共通する一般的な優先順位は以下の通りです。
1. 括弧 ()
2. 単項演算子 (+, -, NOT)
3. 乗除算 (, /, %)
4. 加減算 (+, -)
5. 比較演算子 (=, <>, <, >, <=, >=, LIKE, IN, BETWEEN, IS NULL)
6. 論理演算子 AND
7. 論理演算子 OR
このリストを見て「ORが一番低い」という点に注目してください。これが実務で最も多くのバグを生む原因です。
実務で頻出する「ORの罠」
例えば、あるECサイトの顧客データベースから「東京在住」または「大阪在住で、かつVIP会員」であるユーザーを抽出したいとします。
誤ったクエリの例を挙げます。
SELECT FROM users
WHERE address = ‘Tokyo’ OR address = ‘Osaka’ AND status = ‘VIP’;
このクエリの結果は、意図したものとは異なります。優先順位により、まず「address = ‘Osaka’ AND status = ‘VIP’」が評価され、その結果に対して「address = ‘Tokyo’」がOR条件として追加されます。つまり、「東京の全ユーザー」と「大阪のVIP」が抽出されてしまいます。もし「東京のVIP」だけを抽出したかった場合、このクエリは致命的な論理エラーとなります。
正しくは、括弧を使用して評価順序を明示する必要があります。
SELECT FROM users
WHERE (address = ‘Tokyo’ OR address = ‘Osaka’) AND status = ‘VIP’;
このように、論理演算子を組み合わせる際は、たとえ優先順位を知っていたとしても、括弧を適切に使うことが「可読性」と「保守性」の観点から推奨されます。
パフォーマンスへの影響：インデックスの無効化
演算子の優先順位の理解不足は、単なる論理エラーに留まらず、データベースの性能をも左右します。特に「演算子の優先順位」に関連して、インデックスが効かなくなるケースを見てみましょう。
よくあるのが、列に対して関数や演算を加えてしまうケースです。
— インデックスが効きにくいクエリ
SELECT FROM orders
WHERE (price 1.1) > 1000;
この場合、データベースエンジンはすべての行に対して計算を行ってから比較するため、インデックスが無視される（フルスキャンが発生する）可能性が高いです。優先順位の理解があれば、これを「price > (1000 / 1.1)」と書き換えることで、インデックスを有効活用できることに気づくはずです。
また、論理演算子において「OR」を多用すると、オプティマイザがインデックスの結合をうまく行えない場合があります。特に大規模なテーブルにおいて、ORで繋がれた条件はそれぞれが独立したスキャンを要求することが多く、結果としてクエリの実行計画が大幅に悪化します。
実務におけるベストプラクティス
演算子の優先順位を完璧に暗記する必要はありません。むしろ、暗記に頼ることはリスクです。以下のルールをチーム内で徹底することをお勧めします。
1. 括弧を過剰に使うことを恐れない
優先順位を完全に把握していても、括弧を付けることで「意図」をコードに刻むことができます。将来コードを読み返す自分やチームメンバーのために、迷いそうな場所には必ず括弧を入れましょう。
2. 論理演算子の組み合わせは分解する
ANDとORが混在するクエリは、複雑であればあるほどバグの温床になります。可能であれば、UNION ALLを使用してクエリを分割することを検討してください。
— ORを避けてUNION ALLで記述する例
SELECT FROM users WHERE address = ‘Tokyo’ AND status = ‘VIP’
UNION ALL
SELECT FROM users WHERE address = ‘Osaka’ AND status = ‘VIP’;
この方法は、各クエリがシンプルになり、インデックスも個別に最適化できるため、複雑な条件式よりもパフォーマンスが安定することが多いです。
3. 実行計画（EXPLAIN）を常に確認する
自分が書いた演算子の優先順位がどのように評価され、データベースがどのような戦略でデータを取得しているのかを確認する癖をつけましょう。MySQLであれば `EXPLAIN`、PostgreSQLであれば `EXPLAIN ANALYZE` を使用します。
演算子の優先順位が問われる「NULL」の扱い
最後に、NULLとの比較における優先順位の注意点です。SQLにおけるNULLは「不明」を意味します。比較演算子（=, <>, !=）はNULLに対しては常に「不明（UNKNOWN）」を返します。
もし「statusがNULLではない、かつVIPである」という条件を書く際、以下のような間違いを犯しがちです。
— 意図した挙動にならない可能性がある
SELECT FROM users WHERE status <> ‘Normal’ AND status IS NOT NULL;
ここで、もし優先順位やNULLの性質を理解していないと、論理的な矛盾が生じます。NULLを扱う際は、常に `IS NULL` または `IS NOT NULL` を優先的に評価させるような構成を意識すべきです。
まとめ
演算子の優先順位は、SQLという言語の基礎でありながら、実務では最も軽視されがちな「落とし穴」です。
・論理演算子のORは優先順位が最も低いことを忘れないこと。
・括弧を明示的に使い、誰が見ても挙動が分かるクエリを書くこと。
・パフォーマンスを考慮し、論理的な複雑さを避ける設計を心がけること。
これらの意識を持つだけで、バグの発生率は劇的に下がります。データベース管理者は、単にデータを格納するだけでなく、そのデータを取り出すための「論理」を正しく構築するエンジニアであるべきです。
次回のクエリ作成時には、ぜひ一度「演算子の優先順位」を意識して、括弧によるガードを検討してみてください。たったそれだけの工夫が、深夜のトラブルシューティングを未然に防ぐ鍵となるはずです。
データベースの運用は、小さな積み重ねの連続です。こうした基礎的な知識を軽視せず、常に洗練されたクエリを追求していきましょう。
コメント