1. MySQL5.6 binlog statment格式 主從架構，table的字符集是utf8mb4 插入表情符號的時候，slave無法識別，顯示亂碼
   • 猜想可能是因為binlog字符集默認是utf8格式的。寫入binlog的時候就已經亂碼
2. table的字符集是utf8，並且設置某個字段的字符集類型是utf8mb4。在這個字段插入表情，並且進行pt2.2.19 主從數據同步的時候生成的DML語句也無法識別表情包顯示亂碼。

實驗結果

1. 猜想1不成立，因為binlog的寫入都是二進制。從庫出現字段先睡表情是亂碼的現象猜測可能是因為在做邏輯備份的時候mysqldump默認的字符集是utf8導致的。
   • mysqldump備份的時候默認的是utf8字符集，導致在備份字符集是utf8mb4的table裏面有些數據是表情包的字段顯示亂碼。在導入數據進入的時候還是亂碼。
2. 猜想2成立。
   • table的字符集是utf8
   • table的某個column字符集是utfbmb4
   • table中字符集是utf8mb4的字段有存在表情包
   • 主從復制中這個slave的table的中字段表情包是亂碼
   • 在進行正常的主從同步的時候(即正常的通過binlog傳輸和回放)不會出現slave的表情包顯示是亂碼現象
   • 在pt-table-sync主從數據同步的時候生成的SQL顯示的還是表情包亂碼現象。
   • pt-table-sync --print --charset=utf8 --sync-to-master h=slave_host,u=username,p=‘password‘,P=3306 --databases=schema_name --tables=tables_1,tables_2
   • 在使用pt-table-sync的時候直接使用execute這個參數的時候，假如slave不能同步master，則會修改master的數據使得master同步slave的數據。
   • pt-table-sync --print --charset=utf8 --execute --sync-to-master h=slave_host,u=username,p=‘password‘,P=3306 --databases=schema_name --tables=tables_1,tables_2

【20180626】 pt-table-sync 和slave中的table中的字段存在表情包亂碼