命令：
mysqlbinlog --start-datetime="2017-08-11 11:13:29" --stop-datetime="2017-08-11 11:14:29" mysqld-bin.000002 >2.sql
這是匯出為sql檔案然後匯入sql檔案即可！
或者 mysqlbinlog --start-datetime="2017-08-11 11:13:29" --stop-datetime="2017-08-11 11:14:29" mysqld-bin.000002 |msyql -uroot -p
直接恢復即可！！
恢復的起始時間和結束時間，不包含結束時間點的執行語句。
mysqlbinlog --start-position="8944" --stop-position="10620" mysqld-bin.000003 >3.sql
恢復的起始座標和結束座標，不包含結束座標點的執行語句。
幾個重要的設定說明：
mysql>set表示在當前會話不儲存log_bin日誌，一般在恢復資料的時候使用，恢復資料結束後，設定1即可。sql_log_bin=0;
skip-name-resolve
#禁止mysql對外部連線進行dns解析，使用這一選項可以消除mysql進行dns解析的時間。但需要注意，如果開啟該選項，
#則所有遠端主機連線授權都要使用ip位址方式，否則mysql將無法正常處理連線請求。
「sync_binlog」：這個引數是對於mysql系統來說是至關重要的，他不僅影響到binlog對mysql所帶來的效能損耗，而且還影響到mysql中資料的完整性。對於「sync_binlog」引數的各種設定的說明如下：
sync_binlog=0，當事務提交之後，mysql不做fsync之類的磁碟同步指令重新整理binlog_cache中的資訊到磁碟，而讓filesystem自行決定什麼時候來做同步，或者cache滿了之後才同步到磁碟。
sync_binlog=n，當每進行n次事務提交之後，mysql將進行一次fsync之類的磁碟同步指令來將binlog_cache中的資料強制寫入磁碟。
在mysql中系統預設的設定是sync_binlog=0，也就是不做任何強制性的磁碟重新整理指令，這時候的效能是最好的，但是風險也是最大的。因為一旦系統crash，在binlog_cache中的所有binlog資訊都會被丟失。而當設定為「1」的時候，是最安全但是效能損耗最大的設定。因為當設定為1的時候，即使系統crash，也最多丟失binlog_cache中未完成的乙個事務，對實際資料沒有任何實質性影響。從以往經驗和相關測試來看，對於高併發事務的系統來說，「sync_binlog」設定為0和設定為1的系統寫入效能差距可能高達5倍甚至更多。
lower_case_table_names = 1 #實現mysql不區分大小（開發需求，建議開啟）
bin_log備份中使用到的操作：
1.產看最後乙個bin日誌檔案是那個,現在位置
2.啟用新的日誌檔案,一般備份完資料庫後執行
3.清空現有的所用bin-log
mysql5 6亂碼 mysql5 6亂碼
安裝mysql5.6版本遇到乙個問題，字符集亂碼，如下圖 由於是新安裝的本地資料庫，所以一定是配置的事情，查詢資料庫字符集配置，如下 有兩個是latin1的字符集，本人是window7環境，在網路找了很多資料，都顯示為修改 c program files mysql mysql server 5.6...
編譯mysql5 6 編譯安裝mysql5 6
mysqlwget tar zxvf mysql 5.6.33.tar.gz tar zxvf cmake 2.8.5.tar.gz cd cmake 2.8.5 安裝編譯工具.bootstrap prefix usr local cmake sudo gmake sudo gmake instal...
mysql5 6原始碼 mysql5 6原始碼部署
一.準備環境 環境 centos 7.3 一台 軟體版本 mysql 5.6.39 1.安裝依賴 yum y install autoconf libaio bison ncurses devel 2.建立使用者 groupadd mysql useradd g mysql s sbin nolog...