mysql中使用命令行查看二进制文件filenamenumb每当mysql启动或手动刷新日志后都会新建一个二进制日志文件 。首先我们mysql命令行中，用”show master logs”命令查看已有的binlog文件 。往站点添加数据在网站后台文章模块里，我添加了几条测试数据 。
进入MySQL：启动MySQL Command Line Client（MySQL的DOS界面），直接输入安装时的密码即可 。
查看MySQL系统变量，可以使用show命令，使用select命令查看系统变量 。上述命令分别表示查看当前系统的所有变量 ， 查看所有的全局变量和查看所有的会话变量，以及模糊匹配version，查看当前系统变量 。
将目录中配置文件my.default.ini改名为my.ini移至bin目录下 。启动命令行，将目录切换到mysql安装目录的bin目录下 。
除了 mysqld 文件之外，还有一些其他的二进制文件在 MySQL 安装目录的 bin 子目录中，例如：mysql：用于连接 MySQL 服务器的命令行客户端 。mysqldump：用于备份 MySQL 数据库的命令行工具 。
MYSQL数据库文件的后缀名是什么?1、一个数据库是一个目录，目录下一个表对应三个文件 ， 文件名是表名，扩展名分别是.frm、.MYD、.MYI（数据文件：. myd ）、（ 索引文件：. MYI ）、（表定义文件：. frm） 。
2、主数据文件 。用来存储数据库的数据和数据库的启动信息 。每个数据库必须有且只有一个主数据文件，其扩展名为.mdf 。
3、我说下Innodb和MyISAM两种引擎吧 。对于MyISAM，其索引和数据是分开的，索引文件后缀名是MYD ， 数据文件后缀名是MYI 。对于Inoodb，索引和数据都在同个文件，ibdata.具体的可以查MySQL参考手册（有中文版） 。
4、show variables like %innodb_data%；这里.如果存储引擎是myisam的，其有.frm、.MYI、.MYD三种格式的文件，其中表定义在.frm这里；数据文件保存在.MYD；索引保存在.MYI里 。
5、对于MyISAM存储来说，可以被cache的内容主要就是来源于“.MYI”文件中 。每一个MyISAM表对应一个“.MYI”文件 ， 存放于位置和“.frm”以及“.MYD”一样 。
【mysql存储二进制数据 mysql默认的二进制文件名】6、后缀为sql文件的是microsoft sql server sql脚本语言。
mysql移动后更改二进制日志名字权限问题：请确保从服务器有权访问主服务器的二进制日志 。在主服务器上，你需要设置log_bin参数，并且log_bin_trust_function_creators参数应设置为1 。版本兼容性：二进制日志格式从Statement和Row更改为Statement/Row 。
在这种情况下，需要进行数据恢复或重新配置复制 。二进制日志格式不匹配：MySQL提供了多种二进制日志格式，如Statement、Row和Mixed等 。如主服务器和从服务器配置的二进制日志格式不匹配，复制操作无法正常进行 。
主服务器中的数据自动复制到从服务器之中 。对于多级复制，数据库服务器即可充当主机，也可充当从机 。MySQL主从复制的基础是主服务器对数据库修改记录二进制日志，从服务器通过主服务器的二进制日志自动执行更新 。
MySQL日志文件可分为：重做日志（redo log）、回滚日志（undo log）、二进制日志（binlog）、错误日志（errorlog）、慢查询日志（slow query log）、一般查询日志（general log）、中继日志（relay log） 。
添加下面两行 log-bin=mysql-bin binlog_format=mixed 如果有标首‘[mysqld]’字样，就添加到[mysqld]下，不要添加到其他的下面 。这样就开启了二进制日志，之后做的所有和修改数据表有关的操作都会被记录 。
为什么使用mysqlbinlog无法恢复数据这些要求很好理解，如果重启后数据还在，但是Binlog Event没有了 ， 就没办法复制到其他节点上了 。如果重启后，数据没了，但是Binlog Event还在，那么不存在的数据就会被复制到其他节点上，从而导致主从的不一致 。
恢复指定数据；开启binlog功能及基本操作要使用Mysql的binlog日志功能 ， 首先要在Mysql的配置文件中开启该功能，操作很简单 。找到Mysql的配置文件，在文件中添加一行”log_bin = mysql-bin”即可 。
drop table或者truncate table误删数据表 无法通过Flashback工具恢复 ，因为binlog_format的格式即使是ROW模式 ， 在binlog中记录的也只是一条drop table或者truncate语句，因此无法进行恢复 。
下面是恢复数据的步骤： 停止 MySQL 服务 。找到最后一个正常备份的数据目录，并且将其备份到其他位置 。找到最后一个正常备份的 binlog 文件，并且将其备份到其他位置 。
另外 ， 这两种方法并不能有效的恢复MySQL数据库，可能还会造成数据库被进一步损坏，造成大家无法挽回的损失 。根据以上几个原因，这两种MySQL数据库恢复方法并不建议大家使用 。
主库没有写入数据 。主库的binlogdump线程正好在等待binlog更新，即等待主库写入数据，如果主库一直没有写入数据，dump线程就会等待很长时间 。
