MySQL: 1366 incorrect string value

直接通过新建表后insert into数据，报错如下：

1366 incorrect string value

查看数据库表字段定义，编码格式一致，不知道该如何处理，思考也许是数据库编码格式问题，查询的命令如下：

show variables like ‘character%’;

没有发现异常。
决定另辟蹊径，即通过一条语句完成数据的查询以及表创建。
demo: create table newemp as select * from emp

create table repotest as select s.uuid as repo_uuid, r.url, repo_name, s.language, s.branch, s.repo_source, r.local_addr, s.download_status,latest_commit_time, s.project_name
,s.recycled,import_account_uuid,scan_start, is_private,description 
from sub_repository as s , repository as r
where s.repo_uuid = r.uuid;

报错如下：

1786 statement violates gtid

查询得知：
这是因为在5.6及以上的版本内，开启了 enforce_gtid_consistency=true 功能导致的，MySQL官方解释说当启用 enforce_gtid_consistency 功能的时候，MySQL只允许能够保障事务安全，并且能够被日志记录的SQL语句被执行，像create table … select 和 create temporarytable语句，以及同时更新事务表和非事务表的SQL语句或事务都不允许执行。

CREATE TABLE ... SELECT is not safe for statement-based replication. When using row-based replication, this statement is actually logged as two separate events — one for the creation of the table, and another for the insertion of rows from the source table into the new table just created.

When this statement is executed within a transaction, it is possible in some cases for these two events to receive the same transaction identifier, which means that the transaction containing the inserts is skipped by the slave. Therefore, CREATE TABLE ... SELECT is not supported when using GTID-based replication.

尝试解决这一问题：

SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = off;
或者将上述语句拆分成两句。

使用第一种方案失败。报错如下，无法轻易关闭此模式。

1779 gtid_mode

有点气馁，出现Y问题是为了解决X文件，回到X问题上，思考为什么插入失败，毫无疑问是数据编码格式，决定再次比对编码格式，刚刚在检索过程中得到查询表定义语言的sql如下：

show create table repo;

仔细比对repo、sub_repo以及repository表定义，发明
repo中编码格式定义与repository不一致。
CHARSET=utf8 COLLATE=utf8_bin

保持一致，重新通过表定义语言生成表。
插入成功！

Reference

mysql 官方文档