求救 数据库里不小心 delete 数据怎么恢复

无论能不能恢复，现在第一时间要做的事是完整备份一下，然后抓紧用备份恢复的数据库研究

先把现场备份，然后再准备恢复尝试，如果失败了，还能还原。如果是 VPS 可以把整个 VPS 备份下。 一定要先备份再操作。

目前数据都导出备份了

看看有没有历史的备份点，数据库备份，硬盘快照什么任何的备份点。
然后从那个时间点开始捋所有 binlog，然后在备份点的库上，重跑到目前为止所有 binlog 的 sql

删除之前先 select 查看一下。。。

已经恢复了
数据库前几天建的 中午操作删除的
所以直接把前几天到中午的数据重新恢复遍
把数据库删了 然后
/usr/local/mysql/bin/mysqlbinlog -d mydata --start-datetime='2018-09-04 08:00:00' --stop-datetime='2018-09-06 08:00:00' /usr/local/mysql/var/mysql-bin.000012>/home/mydata.sql
导出 sql
再把 sql 命令行倒回去

看了删除记录
手残啊
where id>19232
变成了 where id>1923

你是不小心删了，我是前两天发现我司有个人删除数据用的是 delete 语句，瞬间无语……

删库到跑路，我以为一直开玩笑，没想到 v 友果然牛皮

@ruihe

删除数据不用 delete 语句，你告诉我怎么删，瞬间无语……

@cncqw 难道不是把更新删除字段？

@cncqw 他应该是说'软删除'吧。数据不是真的删了，只是改变它的某个表明删除的字段

@cncqw 都是逻辑删除了老哥，谁还真的 delete 啊

现在谁还删数据啊 不都是软删除 给字段

我一直觉得 delete 是非常脑残的，奈何产品经理是个洁癖，觉得这些应该删除的数据是脏数据，，，，，，，

除非对文件大小有要求 别删东西啊

@cncqw #10 都是逻辑删除啊..

@cncqw 一般是修改某个字段例如 flag，以这个字段判断这行数据是否为删除状态。

2018 还有真删的？

@cncqw #10 delete_remark 了解一下

@ruihe 删除不用 delete 用什么呀？？？

跑路吧，修复不了的

一直真删，不要抱着侥幸心理。

binlog 重来一次呗

现在都是软删除吧 is_delete

开启 binlog 了么，有的话可以恢复

你们都不看前面楼么，别人楼主已经用 binlog 恢复了，都散了吧。。

软删除只能算更新，跟删除有什么关系？说现在不用物理删除数据的可能只是你们的业务规模太小，当然删不删都无所谓，我做移动广告分析每天产生几千万条数据，你们软删除一个给我试试，真是无语。。

我 3 年前做的项目就已经用上 delete_at 字段了，所以我猜楼上那些教我怎么删除的应该都是 phper，怎么讲，一种认为自己很懂但实际很 low 的感觉扑面而来，很符合 php 这门语言的气质

@cncqw #28 恼羞成怒

和语言有个毛关系……

deleted_at

@cncqw 嚯嚯嚯，来了来了

php: 人在家中坐，锅从天上来

删除数据不用 delete 语句，一般数据都很少

跑路吧，除非按日志恢复，估计搞死人，drop database 然后跑路。。。

@bestkayle #30 人家说的有啥不对

又 block 了几个人，好开心

@zr8657
@ruihe
@calming
@batter
@loveCoding

有时候隐私条款会要求真正删除数

mixed delete 的话 binlog 只记录删除的这一条 sql 你可以看到了，没法从 binlog 恢复 只能从历史备份恢复，之后如果性能没问题，数据又重要还是 row 吧 还有就是多做备份 有备无患

哈哈上面 show is_delete 的好好笑。忍不住了。

新当年我也 delete 过一次，还没加 where 那种，幸亏那张表最近没变化

之前也删过。还好用阿里云的数据库，有备份

1. Select * from ...
2. Delete from ...

先 select 再 delete，后面都一样，复制粘贴就可以。
严格按这个顺序，一般不会出问题。

根据业务需求来决定只不执行物理删除。

ermmm 人家的明文密码啊信用卡号啊身份证号啊手机号啊这些你们都是永久保存的？
贵国的程序员真是可怕。

一切抛开业务场景的技术谈论都是瞎比比

上次是存身份证图片，这次是逻辑删除

在进行数据库操作之前，首先要做的就是备份一下数据
当然数据库过于巨大的工资的话，应该会有自己的备份机制

is_delete... 其实还是看数据规模吧 那种每天在线几百人的 数据产出小的 就没所谓了

数据量大的 不物理删除 等着数据服务器炸掉么...

你需要买一本书：从删库到跑路。()

还恢复啥。。跑路呗

什么鬼，产品经理管天管地数据库模型也要管，这还干个毛，拿起椅子上

@keymao 我不太明白，如果数据量巨大，每天新增上亿的数据量，难道还用数据库来做操作吗？数据库不是作为最后的留存使用吗？不应该是分布式存储，况且我们采集的存储的数据不应该是需要 delete 数据极少数，占比不会超过千分之一甚至十万分之一吧，如果真的需要按照日期删除，难道不应该是按照日期分表，然后去删除表吗？菜鸟一枚，勿喷

做不做物理删除看情况决定吧，说实话，敏感数据，还真没有几个公司是删除了的
顺便楼上那个炮轰的 php 的，笑死我了，php 真的是人在家中坐，锅从天上来

select * from table where deleted_at is not null;

可以从日志恢复嘛，不是很了解。
公司用 Oracle，可以从日志恢复。

@cncqw 稍微翻了一下你以往的回复记录，回复最多的恐怕就是 php 相关的讨论，我猜你可能是一名 phper,至少曾经是的。而你竟然可以把 phper 变成侮辱性词汇，真是讽刺，已 block

MySQL 有闪回工具

日志 sql

该做 log 备份了

嗯 命令行是比图形界面方便

恩。相信我。你以后一定在操作删除操作的时候瑟瑟发抖。。

delete 的时候。一定要加一个 limit。。。

没有有效的备份，那么请节哀

设置个 isDelete 字段，逻辑删除，默认 0，逻辑删除更新值为 1

呃 为啥不试试先锁表，然后根据备份搭建主从，然后开启复制 start ...到 delete 之前呢？不过这个情况需要你的备份里面有 binlog file 和 position 信息或者是 gtid 信息吧,还有就是明确的知道你这个 delete 的 position 信息啊

逻辑删除还是用 delete 还是需求决定的吧，楼上那些纠结这个的真的可笑啊。而且贴主这个还不一定是在程序环境中，可能是清理数据呢。

@IllBeBack 我一般都是这样用

都是些玻璃心

sql server 中的 truncate 删除了解下，敢这么用的人一定是和公司有仇的

@nosay 这个人经历了什么？
@cncqw

看着楼上各位的逻辑，终于感受到无责任心的公司为啥这么多了

抛开业务场景谈技术实现，跟抛开计量谈毒性一样，都是耍流氓。（逃～