2018 年 5 月 15 日，周二，17 : 57 : 06 ，我误操作导致数据库全表更新。

起因是接到一个需求，需要对单独一个用户重设其数据库的字段，本来是一条简单的 SQL ，但是我忘了添加 where 条件就直接提交了，结果就是涉及到用户资产的这张表被全表更新，几十万资产信息错误。

犯下这个严重的错误之后，我立即找 leader 汇报情况，也第一时间联系了运维人员尝试进行数据恢复，但运维因为种种原因在尝试了几个小时之后，遗憾的通知我们无法恢复数据。于是，我们不得不从通过梳理用户的订单数据准备重写资产表，当天晚上，leader 陪我熬了整整一个通宵整理原来的订单和资产相关的业务逻辑（毕竟我刚来一个月，还不熟悉，接手的也是别人遗留下来的烂摊子），然后整理出了第一版的恢复脚本。

周三凌晨五点半左右，在和 leader 反复对比确认后，进行了第一次数据恢复，然而事实证明这一次的尝试是失败的，因为太过于着急和疲惫等等因素，数据恢复脚本逻辑上遗漏了很多地方。因为害怕进一步影响，我们关闭了支付通道，然后重新梳理业务流程和数据恢复逻辑，这一次，不敢再直接操作生产数据了，而是备份生产数据到本地，然后把复杂的流程和逻辑拆分成几个小的部分分别处理，并且先注释掉实际 SQL 操作的部分，模拟恢复流程输出日志信息，记录原始错误的数据、逻辑点关键数据、将会执行的 SQL 语句、受影响的记录等统计数据，通过观察模拟操作输出的日志信息进行统计并回溯逻辑，然后发现问题重新调整并重新模拟，一直循环往复这个过程，直到第二天零点半左右，第二版的恢复流程和脚本整理了出来，但是我们并没有直接上到生产上执行操作，而是回家休息去了。

周四，一觉醒来，突然发现前一晚整理的流程存在致命缺陷，还好前一晚没有着急更新数据，不然又是错上加错。整整一天，不断发现新的问题和遗漏的地方，不断进行模拟、统计、分析、调整、再模拟这样的循环往复的过程。最后，反复对比本地模拟恢复后的数据，并确认无误后，进行了生产数据的更新恢复，并且重新开通了支付通道，事实证明，这一次的恢复成功了一半。

周五，之所以说上一次恢复只成功了一半，是因为原本误操作全表更新的只有三个字段，因为恢复也只针对了这三个字段，但是业务上有关联的另一个字段却并没有进行相应的恢复调整，因此，当天针对这个额外的字段重刷了一遍数据，与此同时，又发现了新的问题，那就是历史遗留的原因导致部分订单数据是存在问题的，还有活动赠送的记录并没有写入到订单或其他表中。

周六，继续填坑，重新整理之前活动相关的部分，只能拉取原始的 Excel 表单去操作恢复数据。

周日，也就是今天，仍然有少量用户数据异常，但这种情况只能单独额外处理。

总结

1、能够走正常业务流程的，不要走后台直接去改数据。不能走正常流程，说明流程本身是不完整的。

2、数据备份，这个不用说了，但是依赖运维却发现没用的时候怎么办，对于用户资产这种关键的数据表，是不是可以自己额外的备份，或者在数据库中索性写入另一张完全相同的表做冗余处理，这样即使出现全表误更新或删除的情况，另一张表也不受影响，我们可以直接切换过去。

3、老旧系统迁移的历史数据，能丢掉就丢掉，数据是很宝贵，但无用的老旧数据对新系统来说更多时候是被埋藏的地雷，就等着你某一天去踩。

4、一定要保证重要数据的连贯性和正确性，像活动相关的数据居然没有完整的记录到数据库中，而是直接走后台改写了这些人的订单数据，结果导致与未参加活动的订单混淆在一起无法区分了，额外加个字段记录下都不行吗？

5、原来的 bug 导致的异常数据及时处理掉，bug 是修复了，数据还放在那里，也不打个标记，伪装得跟正常数据一样这不是害人吗？

6、操作生产数据，一定要先在本地模拟、观察、统计、分析，前后对比，确认无误再进行操作。

7、出了问题，不能着急，越是着急就越容易引发新的问题，千万要避免错上加错。

8、多想想后期怎么维护，不仅是程序，数据也是一样的。

9、问题还有很多，先写这么一点吧。

人生中第一次误操作，记录一下，永生难忘。