今日午休醒来，有点懵，测试环境truncate表时，清错了一张配置表，需要恢复。
但是该机器上没有备份机制，开发环境到是有，但极有可能数据不同步。
然后开始binlog按时间，与表名，确定了binlog的 --stop-position,但是没有用，因为binlog都是配合备份数据弄的，binlog只是导出执行日志，在当前状态下，再执行一遍，因为没有数据，都是update操作 依然还是空数据。
如果配合备份数据，恢复到之前某时刻状态，再用binlog将那个时刻到现在truncate之前操作再执行一遍，就是比较完美的思路。
后面多方查找，
好在同事之前做代运营，copy了一份环境，日期比较近，就直接先表数据弄好，再将binlog较长时间的操作导出。
binlog给人查看的文件导出命令：
mysqlbinlog --no-defaults --skip-gtids --start-datetime='2020-08-21 13:30:00' --stop-datetime='2020-08-21 15:00:00' --database=sm_xxx --base64-output=decode-rows -v /binlog_file_path/binlog.0000000x |grep -i -A 5 -B 5 truncate > /tmp/binlog0xx_trun.log
--no-defaults 用于解决字符集不识别 或其他小异常问题
--skip-gtids 用于忽略gtids范围选择
--start-datetime --stop-datetime 用于筛选日志时间段，日志导出来后，每行最前面 就是 最前面是长数字 然后 时分秒。
--database 选择库
--base64-ouput=decode-rows 就是我们binlog使用row的方式，用于解密，用于人来看
-v 则是将注释类的语句也显示出来
grep -i表示 忽略大小写 -A 5 则是同时显示命中行的后5行(after) -B 5同时显示命中行的前5行(before)
binglog导出 mysql中的用于source执行的文件命令：
mysqlbinlog --no-defaults --skip-gtids --start-datetime='2020-04-21 00:00:00' --stop-position=xxxxxxx --database=sm_xxx /binlog_file_path/binlog.00000xx |grep -i -B 100 tablename >binxx_recover_timestampe_to_now.sql
这里 -B 100 其实是有风险的，可能不包括tablename表操作的也去执行了，一般不加。(我是备份其他表，然后尽量补全目标tablename表)，后面在恢复其他表。（其实可能是我多此一举，因为同样影像行数为0）
后面有缺失的配置，再慢慢补了，唉，以后头晕脑胀的时刻，千万不要执行高危操作，不然就要删库跑路了。