MySQLは最初からRDBMSだったわけではない 初期MySQLの実態：トランザクションがない なぜそれで成立していたのか 転機：InnoDBの標準化 ACID特性の導入 それでも残っていた“昔の挙動” 第二の転換点：MySQL5.7 なぜ変化が必要だったのか 移行時に起きる混乱 …

MySQL5.6までと5.7以降は“同じDB”ではない 最大の変化：SQLモードのデフォルト変更 なぜアプリケーションが壊れるのか STRICTモードの影響 日付の扱いも変わる インデックスと最適化の変化 文字コードと照合順序 5.6と5.7の思想の違い ORMやフレームワークへ…

古いMySQLで作られたシステムを移行すると、なぜ壊れるのか 壊れるのは「データ」ではなく「前提」 新しいMySQLは“間違い”を許さない なぜ古いMySQLは寛容だったのか 移行時に起きる典型的なトラブル 1. GROUP BY問題** 2. 日付の扱い** 3. 文字コード** ORM…

MySQLのONLY_FULL_GROUP_BYで突然アプリが落ちるのは「厳しくなった」からではない ONLY_FULL_GROUP_BYとは何か 何が問題になるのか なぜエラーになるのか（重要） 実際に起きていたこと なぜ本番だけ落ちるのか よくやる危険な対応 正しい修正方法 なぜこの…

MySQLアップデートは「DBの作業」ではなく「アプリ改修」 最初に発生する：接続できない 次に発生する：SQLが通らない GROUP BYエラー 暗黙の型変換 文字コードが原因の不具合 日付データが登録できない 表示は動くが結果が変わる sql_modeを外す対処の落と…

MySQL 8.0は「厳しくなった」のではなく「データベースになった」 SQL標準への接近 なぜSQL標準が重要になったのか 代表例：曖昧な型変換の禁止 日付の扱いが変わった理由 ONLY_FULL_GROUP_BYが有効になった理由 なぜ急に変更されたのか 厳格モード（STRICT_…

MySQL 5.7と8.0の違いは「速くなった」ではない MySQL 8.0で最初に衝突する「SQLモード」 GROUP BYで突然エラーになる ONLY_FULL_GROUP_BYの影響 文字コードのデフォルト変更（地味だが一番危険） インデックス長制限に引っかかる データディクショナリの刷…