凌晨收到消息，说生产库一张千万级表被清空了。原因是运维执行清理脚本时。条件写错了一个字段。备份是前一天晚上的，恢复要几小时，业务基本停摆。
删除要走流程
第一步是确认影响范围：先跑查询语句看会删掉多少行、是哪些数据，把结果给提出需求的人确认。先算再花。直接执行删除语句，等于闭着眼睛开枪。第二步是留备份。把待删的数据先导出一份存起来，哪怕只保留一周。并行会不会乱？
这一步成本极低，但能救很多次命。见过太多人说"删了就删了"，然后花两天找回。业务数据尽量用软删除：打个删除标记，页面上不显示，数据还在库里。这样误删能一键恢复，也不用担心关联表的数据完整性。
软删优先于硬删
代价是存储和查询要多考虑。真正需要物理删除的通常是隐私数据或者体积过大的日志。这类删除要格外谨慎，因为不可逆。建议加二次确认、加延迟执行（比如标记后七天再真删），留出反悔时间。
开发和运维不应该在日常工作中持有删除权限。需要删除时走申请、由专人执行与执行后记录。这个流程看着繁琐，但正是它挡住了大部分误操作。
权限要分开
生产库的删除权限最好只给少数人，并且操作要留审计日志：谁以及什么时候跟删了什么和影响多少行。出事时能追溯，平时也能形成约束。我还想补一句：数据删除是不可逆操作，凡是不可逆的，都要有确认、备份和权限三道关。这套东西谁维护？
数据清理的常见疑问
误删数据怎么恢复
优先用备份恢复，配合数据库日志做时间点恢复。若为软删除可直接改标记恢复。
软删和硬删怎么选
业务数据优先软删，便于恢复；隐私和超量日志类可硬删，但需延迟与二次确认。
谁能有删除权限
建议仅少数专人持有，并配合申请流程与操作审计日志。
末尾补一个细节：批量操作要分批执行。一次删十万行和分十次删一万行，出问题时的影响面完全不同。分批还能在中途停下来检查，避免一错到底。
清理前还要确认有没有关联数据。一张订单删了，对应的支付记录、物流记录和售后工单还在，查起来就是断的。先理清关联关系再动手。
总结：删数据要有三道关：确认范围、留备份与分权限。不可逆的操作，慢一点才对。