MySQLが厳格化した背景とSQL標準の関係

MySQL SQL標準 ONLY_FULL_GROUP_BY STRICTモード データ整合性

MySQLはなぜ突然“厳しく”なったのか

最近のMySQLを触っていると、昔よりエラーが増えたと感じることがあります。
以前は動いていたSQLが通らない、INSERTが拒否される、警告ではなく例外になる。そうした変化です。

これは偶然でもバグでもありません。
MySQLが「壊れた」のではなく、**RDBMSとしての振る舞いに近づいた結果**です。

背景にあるのは、SQL標準（SQL Standard）への接近です。
つまりMySQLは「独自仕様の便利なDB」から「標準に従うDB」へ方向転換しました。

そもそもSQL標準とは何か

SQLには仕様書があります。
ANSI SQL、あるいはISO SQLと呼ばれるものです。

これは「データベースとはどう振る舞うべきか」を定めたルールです。
重要なのは、単なる文法規則ではない点です。

SQL標準は次の考え方を前提にしています。

  • データは一貫しているべき
  • 結果は決定的であるべき
  • 曖昧な問い合わせは許されない

この思想に基づくと、実は昔のMySQLの挙動はかなり特殊でした。

GROUP BYが象徴する問題

典型例です。

SELECT id, name
FROM users
GROUP BY id;

このSQLは、標準SQLでは誤りです。
なぜなら、idごとに複数のnameが存在した場合、どれを返すか決められないからです。

標準SQLでは「決まらない結果」は許されません。
そのためエラーになります。

しかし昔のMySQLは実行しました。
そして「どれか1件」を返しました。

ここに問題があります。
結果が偶然に依存するのです。

なぜ昔のMySQLは標準に従わなかったのか

理由はシンプルです。
対象ユーザーが違ったからです。

当時のMySQLの主な利用者は研究者でも企業DBAでもなく、Web開発者でした。

  • 掲示板
  • 個人サイト
  • 簡易CMS
  • 小規模EC

求められていたのは整合性より「動くこと」でした。
SQLが多少間違っていても結果が出る方が歓迎されたのです。

結果としてMySQLは「開発者に優しいDB」になりました。
ただし、その優しさは標準からの逸脱でもありました。

転機：企業利用の増加

状況が変わったのは、MySQLが業務システムで使われ始めてからです。

業務システムでは、曖昧な結果は問題になります。

  • 売上が変わる
  • 在庫が狂う
  • 請求が変わる

ここでは「それっぽい値」は許されません。
再現可能な結果が必要です。

この要求に応えるため、MySQLは方針を変えます。
SQL標準への準拠です。

STRICTモードとSQLモード

MySQL5.7以降で導入された変更の中心がSQLモードです。

代表的なものです。

  • ONLY_FULL_GROUP_BY
  • STRICT_TRANS_TABLES
  • NO_ZERO_DATE

これらはすべて「曖昧さの排除」が目的です。

例えば次のSQLです。

INSERT INTO users (age) VALUES ('abc');

昔は0として保存されました。
現在はエラーになります。

これは不便になったのではありません。
データの意味を守る方向に変わっただけです。

なぜ厳格化は避けられなかったのか

理由は互換性です。
皮肉に聞こえますが、厳格化は互換性のためです。

現在のシステムは複数のDBを使います。

  • PostgreSQL
  • Oracle
  • SQL Server

それぞれで挙動が違うと、アプリケーションの移植が困難になります。
そのためSQL標準が存在します。

MySQLも企業用途で使われる以上、独自挙動のままではいられませんでした。

開発者が受ける影響

厳格化の影響は主に次の部分に出ます。

  • 集計処理
  • 入力検証
  • 日付処理
  • NULL処理

特に影響が大きいのがNULLです。
MySQLは以前、NULLを暗黙に変換することがありましたが、現在は拒否される場面が増えています。

そのため、アプリ側でバリデーションを行う必要が高まりました。

よくある誤解：MySQLが使いにくくなった

「昔の方が使いやすかった」という声は確かにあります。
ただ、それは操作性の話ではありません。

以前はデータベースがアプリのミスを吸収していました。
現在は吸収しません。

つまり使いにくくなったのではなく、責任の位置が変わりました。

昔

  • アプリが間違えてもDBが補正

現在

  • アプリが正しい値を渡す前提

移行で問題が起きる理由

古いシステムは「補正される前提」で設計されています。
そのため新しいMySQLではエラーになります。

移行時に起きる現象です。

  • 会員登録が失敗する
  • 集計が止まる
  • 検索が例外になる

コードのバグではありません。
設計の前提が変わったためです。

どう対応すべきか

対応は単純ですが手間がかかります。
SQLを修正します。

具体的には次の作業になります。

  • GROUP BYの見直し
  • 型変換の明示
  • 日付の正規化
  • NULL処理の明示

これは単なる修正ではありません。
データの意味を定義し直す作業です。

まとめに代えて

MySQLが厳格になったのは、開発者を困らせるためではありません。
データベースとして当たり前の振る舞いに近づいただけです。

昔のMySQLは「動くこと」を重視していました。
現在のMySQLは「正しいこと」を重視します。

その違いは小さく見えて、システム設計に大きな影響を与えます。

MySQLのバージョンアップが難しいのは、機能追加のせいではありません。
それは、これまで曖昧だった仕様が明確になる瞬間だからです。

そして移行作業とは、DBの更新ではなく、システムが扱っているデータの意味を確認する作業になります。