MySQL 相关项目 MariaDB Drizzle 参考文档 http://mysql-python.sourceforge.net/MySQLdb.html 服务器没有再写东西进去了，就这样停着...
mysql> show global variables like 'log_bin'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | log_bin | OFF | +---------------+-------+ 1 row in set (0.04 sec) 有希望救回来吗？ 在网上搜了一些文章，几乎都是依靠日志救回来的。。。
 | 1 DoctorCat Nov 3, 2020 跑路吧兄弟 |
 | 2 shakaraka PRO 建议出国 |
 | 3 fengpan567 Nov 3, 2020 无了 |
 | 4 zm8m93Q1e5otOC69 Nov 3, 2020 你没了兄弟 |
 | 5 PonysDad Nov 3, 2020 via iPhone 问问是不是有无系统快照，没有就快逃，快逃，快逃。。。 |
 | 6 pppguest3962 OP ... |
 | 7 jiezhi Nov 3, 2020 via iPhone 磁盘恢复？ |
 | 8 irytu Nov 3, 2020 via iPhone 没开 log 基本是毁了 估计没啥 recovery 的方法 |
 | 9 kiracyan Nov 3, 2020 跑路 |
 | 10 Kaiv2 Nov 3, 2020 好奇是怎么不小心 truncate 的 |
 | 11 xdsty Nov 3, 2020 binlog 没开啊，也不是啥重要的数据吧 先找找有没有全量备份的数据 |
 | 12 AkideLiu Nov 3, 2020 via iPhone 快点搜一下哪个国家还没签引渡，争分夺秒啊 |
 | 13 zzzain46 Nov 3, 2020 TRUNCATE 不记录二进制日志文件，无法通过反解析二进制日志文件恢复删除的数据 |
 | 14 ElmerZhang Nov 3, 2020 truncate 的原理是创建一张新表，把原表直接删除掉。 如果是用的 MyISAM 引擎的话，可以看看有没有办法恢复文件。 |
 | 15 oneoyn Nov 3, 2020 binlog 有没有 |
| 16 pppguest3962 OP  9 谢谢各位兄弟关心， 总共 truncate 了 4 张表，其中有一张估计 400W 条左右 表说重要也重要，也不重要，功能是一个类似 index + sum 资料的索引表，请求没有查到的话，服务器会去做一些占时成本很高的运算，然后再把结果加进来而已，还好刚过了月末汇总期，这个表（包括整个服务器）请求量不大，月初停一下问题不大，有 6 月份的备份整表，还是能勉强应付的 还好这里不是数据就是金钱的地方 手贱是不应该的 老问题，新事故了：MySQL 新手操作，Navicat 12 的 F6 多窗口，反正就是眼黑，还是怎么了，把命令贴错地方(测试库和正式库没分清楚） 发帖前经过搜索已有答案，看了已经觉得救回来很困难了，只是看看有无北斗星高手的一句话来点化路子而已 7 点到现在，没喝水没吃饭，抽了一包利群 现在去麦当劳 感谢各位兄弟关心。真的很感谢！！！ |
 | 17 lscexpress Nov 3, 2020 @pppguest3962 下次操作前，把车票先买好 |
 | 18 iwiki Nov 4, 2020 无解，之前我也误操作过，后来通过自己的日志表重新组合，算是恢复了 |
 | 19 ericgui Nov 4, 2020 为何总是直接操作生产数据库呢？ 虽然我也这么做，每次都如履薄冰 |
 | 20 xfabs Nov 4, 2020 via iPhone 1 正式库，一个人写 SQL 另外一个人执行，这样稳点。 |
 | 21 whywhywhy Nov 4, 2020 还不赶紧买 NAS 备份？ 重要的数据库，必须 NAS 备份，白群晖！ 重要的数据库，必须订阅同步到备用数据库！ 重要的数据库，必须每天的完整备份和 N 次的差异备份！ 上次备份在六月份？偷懒一时爽，出事火葬场咯老哥。。。 安全措施从来都是 1 、2 、3 、4，不搞措施，不搞预案，手工做大量 /危险数据操作不先备份，不先 select，平时也不备份，，，，只能说事故绝对不是偶然，而是必然。 上面说叫你跑路真的是没错，你什么预防措施都不搞，出问题你就只能跑。 |
 | 22 littlewing Nov 4, 2020 via iPhone 没备份就准备跑路吧，只有 binlog 也救不回来的 |
 | 23 dbpe Nov 4, 2020 我的习惯..一切的都在本地写好 sql...到服务器 mysql cli 执行.. |
 | 24 openbsd Nov 4, 2020 还真有生产系统不做备份的大神 ？  |
 | 25 avenger Nov 4, 2020 用 RDS 的好处出来了 |
 | 26 kiddingU Nov 4, 2020 ide 连接的账号最好是只能读的账号，因为一不留神就点错了，其他操作还是去终端下面执行比较好 |
| 27 kiddingU Nov 4, 2020 客户端居然还能连接生产环境数据库，只能说一句握草 |
 | 28 zone10 Nov 4, 2020 我一直认为被菜鸟删库了只能是上面人的锅, 跟你无关 |
 | 29 nocrush Nov 4, 2020 本地连接生产的话，就直接来一个可读账号吧 |
 | 30 zgray2580 Nov 4, 2020 可以对账号进行权限设置，也就是楼上说的 可读账号，只有 select update 这些 这样能避免误操作 |
 | 31 mikicomo Nov 4, 2020 生产库，当然是发邮件，让运维执行，要不就提工单 |
 | 32 tesguest123 Nov 4, 2020 via Android @mikicomo binlog 都不开哪有什么运维，估计就是开发=需求+前端+运维+测试。手动狗头… |
 | 33 justseemore Nov 4, 2020 生产库有 truncate 权限？ niu beeeeeeeeeeeeeeee 爆破音 |
 | 34 randomuuid Nov 4, 2020 这就属于就怕万一的万一；生产库给了权限，我都会先备份再操作，扛不起。 |
 | 35 weiwenhao Nov 4, 2020 Navicat 正式数据我都设置 color 为红色,,防止看错, 每次操作完第一件事就是关闭连接.. |
 | 36 imycc Nov 4, 2020 账号权限要细化，普通业务账号就只开查询和更新的权限，truncate 这种杀器只应该 DBA 有，普通运维都不应该拿着。就怕哪天误操作。 至于 Navicat 直连生产环境，我也是不建议的。其实命令行直连也是不建议的，你这种分不清测试和生产环境的坑我们也踩过。。 保险一点的做法，应该是 SQL 在测试环境验证完，提交给 DBA 申请变更，审批之后通过系统自动执行，才能比较好地避免犯糊涂。 不过你们还用着 mysql5.1 。。我说的那些估计都没有吧。。。那就只能根据人力情况，自己规范自己了。至少定时备份得加上，最后的兜底手段了。 |
 | 37 GBdG6clg2Jy17ua5 Nov 4, 2020 via iPhone 跑路吧。即使有 binlog 也是恢复不了的，truncate |
 | 38 OldHu Nov 4, 2020 老兄试试看这个软件 DBRECOVER for MySQL，看看有没有机会恢复数据: https://www.parnassusdata.com/zh-hans/node/1342 @pppguest3962 |
 | 39 zsl199512101234 Nov 4, 2020 以前待过一家公司,凌晨 1 点有人执行了 drop database,直接 gg |
 | 40 WytheHuang Nov 4, 2020 像我们公司开发只有正式库的查询权限，删不了库。 |
 | 41 chengz Nov 4, 2020 账户权限控制太重要了 |
 | 42 MySong Nov 4, 2020 truncate 无法通过 binlog 回滚 |
 | 43 mazhan465 Nov 4, 2020 有点实力 |
 | 44 iminto Nov 4, 2020 |
 | 45 eamon666 Nov 4, 2020 @pppguest3962 后端 都是人下人 |
 | 46 GaoGeYang Nov 4, 2020 via iPhone 跑路 |
 | 47 cs371332219 Nov 5, 2020 via Android 上云了没，上云的话，问问厂商有没有快照 |
 | 48 Achiii Nov 5, 2020 (测试库和正式库没分清楚） 也太真实了 ，但是 truncate 不能回滚 |
 | 49 dany813 Nov 5, 2020 可怕。没开定时备份吗 |
 | 50 lx0758 Nov 5, 2020 去这个网站看看吧, 可能会有点用 http://www.airchina.com.cn/ |
Select Language