После переезда с версии MySQL 5.5.13 на 5.6.10 стали вылезать странные грабли.

Симптом №1:

Caused by: java.sql.SQLException: Incorrect string value: '\xE6\xAF\x94FOX...' for column 'parameter_value' at row 4
        at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1078)
        at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4190)

Симптом №2:

Data truncation: Data too long for column 'channel' at row 1
org.hibernate.exception.DataException: could not execute native bulk manipulation query

Так как "раньше всё работало" и в код приложения никто изменений не вносил, закралось подозрение, что новый mysql работает в каком-то более строгом режиме. Гугление вывело на глобальную переменную sql_mode.

mysql> show global variables like 'sql_mode';
+--------------------------+--------------------------------------------+
| Variable_name            | Value                                      |
+--------------------------+--------------------------------------------+
| sql_mode                 | STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION |
+--------------------------+--------------------------------------------+

Читаем официальное руководство и видим:

STRICT_TRANS_TABLES
If a value could not be inserted as given into a transactional table, abort the statement. For a nontransactional table, abort the statement if the value occurs in a single-row statement or the first row of a multiple-row statement.

На основе этой инфы приходит в голову мысль, что надо этот режим STRICT_TRANS_TABLES попробовать отключить:

mysql> SET GLOBAL sql_mode = 'NO_ENGINE_SUBSTITUTION';
 
mysql> show global variables like 'sql_mode';
+---------------+------------------------+
| Variable_name | Value                  |
+---------------+------------------------+
| sql_mode      | NO_ENGINE_SUBSTITUTION |
+---------------+------------------------+

И таки да, после этого запросы, ранее выполнявшиеся с ошибками, стали отрабатывать нормально, как и было на версии 5.5.13. Чтобы сохранить изменения навсегда, в /etc/my.cnf я добавил в секции [mysqld]

sql-mode="NO_ENGINE_SUBSTITUTION"

Однако далее меня ждала еще одна засада – после рестарта mysql-сервера я опять увидел знакомую картину, несмотря на внесенные в /etc/my.cnf изменения:

mysql> show global variables like 'sql_mode';
+--------------------------+--------------------------------------------+
| Variable_name            | Value                                      |
+--------------------------+--------------------------------------------+
| sql_mode                 | STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION |
+--------------------------+--------------------------------------------+

Это было непостижимо и удивительно. Я уже и еще раз проверил hostname у сервера, дабы убедиться, что всё ранее сделанное происходило именно на том сервере, где и должно было происходить. Почесав пару минут репу, решил проверить наличие других конфигов mysql-сервера в системе. И таки нашёл один такой в /usr/my.cnf:

$ cat /usr/my.cnf | grep -vE "^#" | sed -r "/^$/ d"
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES

Вот он, вражеский конфиг, который переопределял моё значение sql_mode! Что самое прикольное, больше ничего в этом конфиге не было. Как будто его специально всунули, чтобы добавить мне головняка. После удаления файла /usr/my.cnf и рестарта mysql-сервера я уже раз и навсегда получил возможность наслаждаться значением sql_mode без STRICT_TRANS_TABLES.