1 找个别的机器安装个同版本的mysql或从已安装同版本的其他机器上（非同版本的也可以试下）：
创新互联建站是一家专业从事网站设计制作、网站设计的网络公司。作为专业网站制作公司,创新互联建站依托的技术实力、以及多年的网站运营经验,为您提供专业的成都网站建设、营销型网站建设及网站设计开发服务！
拷贝 mysql/data/mysql 目录到你的mysql/data/ 下吧
2 试着启动mysql服务，如果能启动了，理论上应该丢失的只有用户、授权等一些系统信息，不影响你的使用的数据；
如果不能启动，看错误日志，争取启动了。
3 赶紧把数据备份一份出来，重新把所有库（只是你后来创建的业务相关的库，不包括mysql库）都删了，重新导入一遍。理论上不这样也可以，但只是非生产重要的环境下。
4 重新做用户授权。
可以尝试：
1、新建一个一样名字的数据库；
2、关掉mysql，把备份的data数据覆盖进现在mysql的data中
3、启动mysql进去看看
打开mysql的bin log功能：
对于mysql也是支持增量备份，但要打开mysql的bin log功能。
我们修改mysql的配置文件。linux是/etc/my.cnf，windows是mysql的安装目录/my.ini
我们在[mysqld]下面加上log-bin一行代码，如下面。
[mysqld]
log-bin=mysql-bin
复制代码
加完后重起mysql即可。
某客户更新数据的时候，误删了数据库的内容，因为数据库做了主从，但是没有做备份（备份很重要啊！）幸好开启了bin-log，之后只好把整个日志的记录拿回来本地进行恢复。
之后自己也做了一个简单的测试，对数据进行恢复，具体如下：
1、新建一个表
CREATE TABLE `lynn`.`sn_test` ( `name` VARCHAR( 10 ) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL , `age` INT( 3 ) NOT NULL ) ENGINE = MYISAM;
2、插入多条数据
INSERT INTO `lynn`.`sn_test` (`name`, `age`) VALUES ('lynn1', '1');
INSERT INTO `lynn`.`sn_test` (`name`, `age`) VALUES ('lynn2', '2');
INSERT INTO `lynn`.`sn_test` (`name`, `age`) VALUES ('lynn3', '3');
INSERT INTO `lynn`.`sn_test` (`name`, `age`) VALUES ('lynn4', '4');
3、查看数据并删除
mysql select * from sn_test;
| name | age |
| lynn1 | 1 |
| lynn2 | 2 |
| lynn3 | 3 |
| lynn4 | 4 |
4 rows in set (0.00 sec)
mysql delete from sn_test;
Query OK, 4 rows affected (0.00 sec)
mysql select * from sn_test;
Empty set (0.00 sec)
4、mysqlbinlog恢复数据
mysqlbinlog mysql-bin.000006 1.sql
查看1.txt里面数据插入的纪录，把删除之前的数据进行恢复
mysqlbinlog mysql-bin.000006 --start-position=2471 --stop-position=2876 | mysql -uroot -p123
重新登录，查看数据，OK，已经成功恢复了
对于数据库操作，应该注意如下问题：
1、要常备份（全备，增量备份），出了问题可以最快恢复数据；
2、操作数据库前，要把需要操作的数据库或者表dump出来；
3、需要把bin-log打开，就算没有做上面的两步，也可以通过日志恢复数据
简单情况下：进入原来mysql安装路径下的data文件夹下，找到相应的库和ibdata1，进行copy，就可回复原来的数据。
复杂情况下：
从另一台机上把MySQL数据库的mysql文件夹拷贝到本地机上，目的是恢复本地机对数据的访问和操作。经过如下几种情况的操作。
1.
在本地重装MySQL（安装目录D:\Program
Files\MySQL\MySQL
Server
5.0），直接把mysql文件夹拷贝至D:\Program
Files\MySQL\MySQL
Server
5.0\。结果，失败：数据库连接错误。
2.
卸载后重装MySQL，将D:\Program
Files\MySQL\MySQL
Server
5.0\下的数据备份，只把mysql\data文件夹全部内容拷贝到D:\Program
Files\MySQL\MySQL
Server
5.0\data下。结果，失败：数据库连接错误。将备份的数据还完覆盖。结果，失败，还是连接不上数据库。
3.
卸载后重装MySQL，将mysql\data文件夹里的cf1,last文件夹（这两个是原来MySQL里的数据库）拷贝进D:\Program
Files\MySQL\MySQL
Server
5.0\data。连接成功，在Navicat
for
MySQL里看到数据库cf1和last，但是不能访问，因为数据全为零。明白了原来data里以数据库命名的文件存储的是数据库的表结构，不是元数据。下一步，把data文件夹里的ibdata1文件（3.4G大，明显存储了元数据）拷贝到D:\Program
Files\MySQL\MySQL
Server
5.0\data里，代替原来的ibdata1文件。重启电脑，打开Navicat
for
MySQL，连接成功，数据可以访问操作。
至此，操作终于成功。其实当初在那台机上把数据导出来，而不是现在直接把文件夹mysql复制过来会更容易恢复。但那台机已经重装了系统，也就是说MySQL失效了。
MySQL 在崩溃恢复时，会遍历打开所有 ibd 文件的 header page 验证数据字典的准确性，如果 MySQL 中包含了大量表，这个校验过程就会比较耗时。 MySQL 下崩溃恢复确实和表数量有关，表总数越大，崩溃恢复时间越长。另外磁盘 IOPS 也会影响崩溃恢复时间，像这里开发库的 HDD IOPS 较低，因此面对大量的表空间，校验速度就非常缓慢。另外一个发现，MySQL 8 下正常启用时居然也会进行表空间校验，而故障恢复时则会额外再进行一次表空间校验，等于校验了 2 遍。不过 MySQL 8.0 里多了一个特性，即表数量超过 5W 时，会启用多线程扫描，加快表空间校验过程。
如何跳过校验MySQL 5.7 下有方法可以跳过崩溃恢复时的表空间校验过程嘛？查阅了资料，方法主要有两种：
1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0 ，那么 validate = false，即可以跳过表空间校验。实际测试的时候设置 innodb_force_recovery =1，也就是强制恢复跳过坏页，就可以跳过校验，然后重启就是正常启动了。通过这种临时方式可以避免崩溃恢复后非常耗时的表空间校验过程，快速启动 MySQL，个人目前暂时未发现有什么隐患。2. 使用共享表空间替代独立表空间这样就不需要打开 N 个 ibd 文件了，只需要打开一个 ibdata 文件即可，大大节省了校验时间。自从听了姜老师讲过使用共享表空间替代独立表空间解决 drop 大表时性能抖动的原理后，感觉共享表空间在很多业务环境下，反而更有优势。
临时冒出另外一种解决想法，即用 GDB 调试崩溃恢复，通过临时修改 validate 变量值让 MySQL 跳过表空间验证过程，然后让 MySQL 正常关闭，重新启动就可以正常启动了。但是实际测试发现，如果以 debug 模式运行，确实可以临时修改 validate 变量，跳过表空间验证过程，但是 debug 模式下代码运行效率大打折扣，反而耗时更长。而以非 debug 模式运行，则无法修改 validate 变量，想法破灭。
如果你要恢复的数据库是包含授权表的mysql数据库，您将需要使用--skip赠款-tables选项来运行服务器恢复整个数据库
- 首先，。否则，服务器会抱怨不能找到授权表。恢复表后，执行mysqladmin冲水privileges告诉服务器装载授权表，并用它们来启动。数据库目录到其他地方的原始内容
复制。例如，您可以使用它们在以后的事后分析检查表（验尸）的崩溃。
酒店与最新的数据库备份文件重新加载。如果您打算使用mysqldump的所加载的文件，则需要输入它们作为mysql的。如果您打算使用从数据库文件直接拷贝（例如，使用tar或CP），它会复制他们直接回数据库目录中。然而，在这种情况下，你应该在关闭之前，该服务器复制这些文件，然后重新启动它。在备份过程中
重做日志，然后查询更新数据库表中。对于所有可用的更新日志，你可以使用它作为mysql的输入。指定--one-database选项，因此MySQL只是要还原的数据库执行查询。如果你意识到有必要使用所有的更新日志文件，可以使用包含以下命令日志的目录：
％LS-TRL更新（0-9）* | xargs的猫| mysql--。一个数据库DB_NAME
ls命令生成一个单独的日志文件更新列表，更新日志文件根据服务器（你知道，如果你其中的任何文件，排序顺序生成的顺序进行排序会发生变化，这将导致在更新日志中以错误的顺序使用）。有限公司您可能需要使用一些更新日志。例如，如果日志，因为命名update.392备份，pdate.393等产生的，可以在命令重新运行它们：
％的mysql - 一个数据库DB_NAME 录入。 392
％的mysql - 一个数据库DB_NAME updata.393 ...
如果您正在运行的恢复，并打算使用更新日志恢复由于失误降数据的基础上，DROPTABLE或DELETE语句和丢失的信息时，一定要在开始更新日志删除这些语句。
恢复单个表
恢复单个表是非常困难的。如果是的mysqldump备份文件生成的，它只是不包含数据，您需要一个表，你需要提取的相关线路，并利用它们作为mysql的输入，这部分比较容易。困难的是，提取在该表的更新日志中使用的片段。你会发现：mysql_find_rows工具在这方面有所帮助，它可以提取多行从更新日志查询。另一种可能性是使用另一台服务器
恢复整个数据库，然后将该文件复制到表的原始数据库。这其实很容易！当文件被复制回数据库目录，确保原始数据库服务器关闭。
