解决MySQL误删数据！快速恢复宝贵数据方法 (mysql 中误删数据后怎么恢复数据)
MySQL数据库是一种广泛使用的关系型数据库，在日常工作中经常会遇到误删数据的情况。如果没有及时有效地进行数据恢复，可能会造成严重的后果。本文将介绍一些快速恢复MySQL误删数据的方法。
方法一：利用备份数据恢复
备份是一种非常有效的数据恢复方法，如果您经常备份数据，那么遇到误删数据的情况也没有必要过于担心。
如果您备份的数据在MySQL中，可以借助MySQL提供的命令来还原数据。具体步骤如下：
1. 打开MySQL命令行界面；
2. 输入以下命令查看你的备份数据：
show databases;
3. 选择你想要恢复的数据库，例如：
use test;
4. 输入以下命令恢复备份的数据：
source /home/backup/test.sql;
其中，/home/backup/test.sql是你备份的数据文件路径。
如果您使用的是第三方备份工具备份的MySQL数据库，您需要首先将备份数据导入到MySQL中，然后再对误删的数据进行恢复。
方法二：使用日志文件恢复
MySQL提供了二进制日志和错误日志两种日志文件。二进制日志主要记录数据库的所有操作，而错误日志记录了MySQL出现的错误。
如果您开启了MySQL的二进制日志，可以利用日志文件来恢复误删的数据。具体步骤如下：
1. 找到你的二进制日志文件，一般情况下是在MySQL的数据目录下，根据你的MySQL版本不同，文件名称可能不同；
2. 根据误删的时间点确定要恢复的操作，例如：
BINLOG ‘mysql-bin.000034’ POSITION 422;
该命令的作用是从第34个二进制日志文件的422号位置开始恢复数据。
3. 在MySQL命令行输入以下命令恢复数据：
mysqlbinlog mysql-bin.000034 | mysql -u root -p
其中，mysql-bin.000034是你要恢复的二进制日志文件名。
方法三：使用文件恢复
如果您的MySQL数据库使用的是MyISAM引擎，那么MySQL会为每个表都创建一个.MYD和.MYI文件，其中.MYD文件是数据文件，.MYI文件是索引文件。如果您误删了数据，可以尝试使用这些文件进行恢复。
具体步骤如下：
1. 停止MySQL服务；
2. 找到误删数据的数据文件和索引文件，一般情况下在MySQL的数据目录下，路径为数据库名称/表名.MYD或.MYI；
3. 复制.MYD和.MYI文件到一个新的目录下；
4. 启动MySQL服务，新建一个表，表结构必须和误删数据的表结构完全相同；
5. 从复制出来的.MYD文件中导入数据：
LOAD DATA INFILE ‘/newdir/lost.MYD’ INTO TABLE test.lost;
其中，/newdir/lost.MYD是你复制出来的数据文件的路径。
方法四：使用第三方工具恢复
如果以上方法都不能恢复误删数据，您可以考虑使用第三方数据库恢复工具。如EaseUS Data Recovery Wizard、Recover My Files、Stellar Phoenix等。
这些工具可以从MySQL数据库备份文件中恢复数据，或者直接从硬盘中搜索MySQL数据文件来恢复数据。
以上是几种快速恢复MySQL误删数据的方法，从备份到日志文件、文件恢复，每种方法都有其特点和限制。因此，在使用前应了解自己的数据库引擎类型和配置情况，并选择合适的数据恢复方法。同时，为了防止数据丢失，我们也要及时备份数据库，以备不时之需。
相关问题拓展阅读：
mysql数据没有备份误删了怎么恢复
打开mysql的bin log功能：
对于mysql也是支持增量备份，但要打开mysql的bin log功能。
我们修改mysql的配置文件。linux是/etc/my.cnf，windows是mysql的安装目录/my.ini
我们在下面加上log-bin一行代码，如下面。
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.> 1.sql
查看1.txt里面数据插入的纪录，把删除之前的数据进行恢复
mysqlbinlog mysql-bin.start-position=stop-position=2876 | mysql -uroot -p123
重新登录，查看数据，OK，已经成功恢复了
对于数据库操作，应该注意如下问题：
1、要常备份（全备，增量备份），出了问题可以最快恢复数据；
2、操作数据库前，要哗樱把需要操作的数据库或者表dump出来；
3、需要把bin-log打开，就算没有做上面的两步，也可以通过日志恢复数据
打开mysql的bin log功能：
对于mysql也是支持增量备份，但要打开mysql的bin log功能。
我们修改mysql的配置文件。linux是/etc/my.cnf，windows是mysql的安装目录/my.ini
我们在下面加上log-bin一行代码，如下面。
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.> 1.sql
查看1.txt里面数据插入的纪录，把删除之前的数据进行恢复
mysqlbinlog mysql-bin.start-position=stop-position=2876 | mysql -uroot -p123
重新登录，查看数据，OK，已经成功恢复了
对于数据库操作，应该注意如下问题：
1、要常备份（全备，增量备份），出了问题可以最快恢复数据；
2、操作数据库前，要哗樱把需要操作的数据库或者表dump出来；
3、需要把bin-log打开，就算没有做上面的两步，也可以通过日志恢复数据
前言
MySQL 5.6引入了GTID，每个事务都会产生一个GTID，我们可以通过验证主从GTID来验证主从数据的一致性。
为了叙述简便，定义一个量ALL_GTID: 表示某个数据库实例上 所有存在过的 或 将要存在的事务 的GTID（包括已经被purge掉的事务）。
在讨论数据库可用性的场景中, 当发生主备切换时, 需要进行数据补偿。通过比较主备的ALL_GTID，可以确定需要补偿多少数据:
在实例存活的情况，可以在实例状态中查询ALL_GTID。
在实例崩溃的情况，无法在实例状态中查询ALL_GTID。可以通过查询BINLOG中的Previous-GTIDs计算来获得ALL_GTID。
下面列举与ALL_GTID相关的变量。
与ALL_GTID相关的变量
Previous-GTIDs
Previous-GTIDs格式如下（环境为MySQL5.7，日志手动flush binary logs获得）：
查看新轮转出的BINLOG：
下面为mysql-bin.00001中包含的GTID：
请点击输入图片描述
然后再次flush binary logs:
请点击输入图片描述
mysql-bin.00002中是没有任何GTID的。
请点击输入图片描述
综上Previous-GTIDs是本身这个BINLOG文件前面的所有BINLOG的。
请点击输入图片描述
全局变量中的GTID相关的变量
请点击输入图片描述
变量解释:
gtid_executed 代表着server上所有事务执行产生的GTID（包含已经被purge的BINLOG中的GTID或者是手动set gtid_purged的GTID）。
gtid_purged 代表着已经被purge到的GTID。gtid_purged是gtid_executed的子集。
gtid_retrieved 是从机上relay_log中的GTID。
ALL_GTID 的计算
了解了GTID相关的变量之后，可以得到获得实例的All_GTID的的方法：
对象
方法
存活的Master实例 gtid_executed
存活的Slave实例 gtid_executed和gtid_retrieved的并集
非存活Master实例 最后一个BINLOG文件的Previous-GTIDs + 最后一个BINLOG文件中所有的GTID
非存活Slave实例 最后一个BINLOG文戚亏件的Previous-GTIDs + 最后一个BINLOG文件中所有的GTID
在获得非存活实例中的ALL_GTID时，最后一个BINLOG文件中的GTID可能不连续(比如事务同时来自于本实例客户端和复制回放)，所以需要扫描最后一个BINLOG文件。
生产中我们使用Xtrabackup来产生一个 从实例 的流程如下：
拉取备份，进行还原
change master to
set @@global.gtid_purged=”;
set @@global.gtid_purged=”; 的影响:
将 从实例 的ALL_GTID手工置为, 在通过GTID方式建立复制时不会出错.
将更新Binlog中记录的Previous-GTIDs (由于Binlog不可改变, 将产生新的Binlog, 记录新的Previous-GTIDs).
MySQL 5.7中set gtid_purged的行为变更
问题描述
回顾一下备份恢复的流历渣程:
拉取备份，进行还原
change master to
set @@global.gtid_purged=”;
现象: 发现有一台MySQL 5.7的Slave服务器恢复后没有产生 正确的Previous-GTIDs。
分析
分析整个过程，解决问题高烂神应该分阶段进行手动模拟发现问题。以下为详细步骤：
手工还原备份
环境
BINLOG数量，Previous-GTIDs状态
Xtrabackup 2.4.2 & MySQL 5.6 1，空
Xtrabackup 2.4.2 & MySQL 5.7 1，空
Xtrabackup 2.2.9 & MySQL 5.6 1，空
Xtrabackup 2.2.9 & MySQL 5.7 1，空
可见: 恢复过程不会轮转BINLOG。
验证change master和set gtid_purged在不同的MySQL版本中执行的差异
环境
BINLOG数量，Previous-GTIDs状态
change master & MySQL 5.6 1，空
change master & MySQL 5.7 1，空
set gtid_purged & MySQL 5.6 2，正常
set gtid_purged & MySQL 5.7 1，空
可见: 执行set gtid_purged时不同版本的MySQL产生了差异
验证
对不同版本MySQL单独执行set @@global.gtid_purged=”;语句。检查结果
环境
进行的操作
BINLOG数量，Previous-GTIDs状态
MySQL 5.7 reset master; set @@global.gtid_purged=”; 1，空
MySQL 5.6 reset master; set @@global.gtid_purged=”; 2，正常
结论
参考:
官方解释: 在5.7版本中，执行SET GTID_PURGED语句后binlog_simple_gtid_recovery会给GTID_PURGED计算出一个错误的值。
由于5.7中新增了存储GTID的表。所以5.7版本中set @@global.gtid_purged=”;语句被改成只修改存放GTID的表。
关于mysql 中误删数据后怎么恢复数据的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。
