この記事の関連です。
#環境
動いていたVersion MySQL 5.6.30
動かなかったVersion MySQL 5.6.33
(ビルドVersionしか違わないのに。。。)
#経緯
検証環境で動いていたSQLが本番環境で動かないとの事で調査開始。
関連記事の件があったので今回もその手の問題だろうとMysqlのオプションから比較してみる。
それぞれの環境でMySQLにログインして
SELECT @@global.sql_mode;
#調査結果
検証環境
+------------------------+
| @@global.sql_mode |
+------------------------+
| NO_ENGINE_SUBSTITUTION |
+------------------------+
本番環境
+--------------------------------------------+
| @@global.sql_mode |
+--------------------------------------------+
| STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION |
+--------------------------------------------+
STRICT_TRANS_TABLES
ってなんぞや?
Google先生からデフォルトが指定されていないカラムに値を設定しないと
怒られる設定だと教えて頂く。
実行されているSQLとテーブル定義を見ると仰る通りの様子。
本来はSQL(というか設計)を見直すべきなのだろうがMySQLの設定を変更する。
SET @@GLOBAL.sql_mode='NO_ENGINE_SUBSTITUTION';
NO_ENGINE_SUBSTITUTION
は
デフォルトのストレージ エンジンの自動置換 (substitution) を防ぐ。これは、CREATE TABLE のようなステートメントが、無効化した、またはコンパイルしたストレージ エンジンを指定するときのこと。エラーで知らせる。
らしいので残しておく。
この時点で正常にSQLを実行できるようになったのだが
MySQLのsql_modeは再起動すると設定ファイルの内容に戻ってしまうので設定ファイルも書き換えておく。
sudo vi /etc/my.conf
変更した部分(変更前の設定はコメント化して残しておいた)
sql_mode=NO_ENGINE_SUBSTITUTION```
`sudo service mysqld restart`
しても`STRICT_TRANS_TABLES`が無効になっているのを確認して終了。