Mysql 5.1.73，不小心 truncate 一张表，也没有开日志，还能恢复么？

[pppguest3962]

服务器没有再写东西进去了，就这样停着...

mysql> show global variables like 'log_bin';  
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin       | OFF   |
+---------------+-------+
1 row in set (0.04 sec)

有希望救回来吗？ 在网上搜了一些文章，几乎都是依靠日志救回来的。。。

[whywhywhy]

还不赶紧买 NAS 备份？

重要的数据库，必须 NAS 备份，白群晖！
重要的数据库，必须订阅同步到备用数据库！
重要的数据库，必须每天的完整备份和 N 次的差异备份！

上次备份在六月份？偷懒一时爽，出事火葬场咯老哥。。。

安全措施从来都是 1 、2 、3 、4，不搞措施，不搞预案，手工做大量 /危险数据操作不先备份，不先 select，平时也不备份，，，，只能说事故绝对不是偶然，而是必然。

上面说叫你跑路真的是没错，你什么预防措施都不搞，出问题你就只能跑。

[littlewing]

没备份就准备跑路吧，只有 binlog 也救不回来的

[dbpe]

我的习惯..一切的都在本地写好 sql...到服务器 mysql cli 执行..

[openbsd]

还真有生产系统不做备份的大神 ？

[avenger]

用 RDS 的好处出来了

[kiddingU]

ide 连接的账号最好是只能读的账号，因为一不留神就点错了，其他操作还是去终端下面执行比较好

[kiddingU]

客户端居然还能连接生产环境数据库，只能说一句握草

[zone10]

我一直认为被菜鸟删库了只能是上面人的锅, 跟你无关

[nocrush]

本地连接生产的话，就直接来一个可读账号吧

[zgray2580]

可以对账号进行权限设置，也就是楼上说的 可读账号，只有 select update 这些 这样能避免误操作

[mikicomo]

生产库，当然是发邮件，让运维执行，要不就提工单

[tesguest123]

@mikicomo binlog 都不开哪有什么运维，估计就是开发=需求+前端+运维+测试。手动狗头…

[zpfhbyx]

生产库有 truncate 权限？ niu beeeeeeeeeeeeeeee 爆破音

[RudyS]

这就属于就怕万一的万一；生产库给了权限，我都会先备份再操作，扛不起。

[weiwenhao]

Navicat 正式数据我都设置 color 为红色,,防止看错, 每次操作完第一件事就是关闭连接..

[imycc]

账号权限要细化，普通业务账号就只开查询和更新的权限，truncate 这种杀器只应该 DBA 有，普通运维都不应该拿着。就怕哪天误操作。
至于 Navicat 直连生产环境，我也是不建议的。其实命令行直连也是不建议的，你这种分不清测试和生产环境的坑我们也踩过。。

保险一点的做法，应该是 SQL 在测试环境验证完，提交给 DBA 申请变更，审批之后通过系统自动执行，才能比较好地避免犯糊涂。

不过你们还用着 mysql5.1 。。我说的那些估计都没有吧。。。那就只能根据人力情况，自己规范自己了。至少定时备份得加上，最后的兜底手段了。

[angryfish]

跑路吧。即使有 binlog 也是恢复不了的，truncate

[OldHu]

老兄试试看这个软件 DBRECOVER for MySQL，看看有没有机会恢复数据:
https://www.parnassusdata.com/zh-hans/node/1342

@pppguest3962

[zsl199512101234]

以前待过一家公司,凌晨 1 点有人执行了 drop database,直接 gg

[WytheHuang]

像我们公司开发只有正式库的查询权限，删不了库。