mysql-MySQL二進制日志使用遇到的編碼問題

來源：懂視網責編：小采時間：2020-11-09 16:34:53

mysql-MySQL二進制日志使用遇到的編碼問題

mysql-MySQL二進制日志使用遇到的編碼問題:日志mysql 以下是MySQL的二進制日志數據，其中問題1：日志中/*!\C binary //!*/; 和 /*!\C utf8 //!*/;是什么作用使用場景：解析二進制日志，存儲到數據庫中再調取出來執行到別一個數據庫問題2：存儲SQL的時候會出現亂碼，如alter table l

推薦度：

點擊下載本文 文檔為doc格式

導讀mysql-MySQL二進制日志使用遇到的編碼問題:日志mysql 以下是MySQL的二進制日志數據，其中問題1：日志中/*!\C binary //!*/; 和 /*!\C utf8 //!*/;是什么作用使用場景：解析二進制日志，存儲到數據庫中再調取出來執行到別一個數據庫問題2：存儲SQL的時候會出現亂碼，如alter table l

日志mysql

以下是MySQL的二進制日志數據，其中
問題1：日志中/*!\C binary //!*/; 和 /*!\C utf8 //!*/;是什么作用?

使用場景：
解析二進制日志，存儲到數據庫中
再調取出來執行到別一個數據庫

問題2：
存儲SQL的時候會出現亂碼，如
alter table lezhi_app.tmp
change etid etid int(11) NOT NULL comment '編號'
其中“編號”就成亂碼了，SQl調取出來執行的時候就會報錯，無法執行？（數據庫默認使用了set names gbk，不使用set names的話也是亂碼）

解決方案：
解析 /*!\C utf8 //!*/ 中的utf8，加上set names utf8 后，可以正常存儲執行

問題2：
很多SQL是在 /*!\C binary //!*/; 下面
執行 set names binary 后，有部分中文SQL存儲出現亂碼（存儲出現 ???）。
（我們數據編碼用的是GBK）

 COMMIT/*!*/;# at 87931309#150108 20:08:13 server id 5 end_log_pos 87931465 Query thread_id=2649685 exec_time=0 error_code=0use `lezhi_app`/*!*/;SET TIMESTAMP=1420718893/*!*/;/*!\C utf8 *//*!*/;SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/;alter table `lezhi_app`.`tmp` change `etid` `etid` int(11) NOT NULL comment '編號'/*!*/;# at 87931465#150108 20:08:13 server id 5 end_log_pos 87931529 Query thread_id=2649874 exec_time=0 error_code=0SET TIMESTAMP=1420718893/*!*/;/*!\C binary *//*!*/;SET @@session.character_set_client=63,@@session.collation_connection=28,@@session.collation_server=8/*!*/;BEGIN/*!*/;# at 87931529

數據庫編碼是這樣的：

圖片說明