17370845950

必须先用SELECT验证WHERE条件再执行DELETE，加LIMIT分批删除，所有操作在显式事务中进行，并严格管控生产环境权限与自动提交。

SQL DELETE语句看似简单，但误操作可能导致数据不可逆丢失。核心原则只有一条：永远不直接在生产环境执行不带WHERE条件的DELETE，也不在未验证条件逻辑前执行带WHERE的DELETE。

先查后删：必须用SELECT验证WHERE条件

任何DELETE操作前，先把DELETE换成SELECT，确认返回的是你真正想删的数据行。

• 错误写法：DELETE FROM users WHERE status = 'inactive' AND created_at
• 正确流程：先执行SELECT id, username, status, created_at FROM users WHERE status = 'inactive' AND created_at ，检查结果集数量、字段值、时间范围是否符合预期
• 特别注意：日期比较要确认时区、字段类型（DATETIME vs TIMESTAMP）、索引是否生效，避免“删少了”或“删多了”

加LIMIT限制：尤其在线上临时清理时

即使WHERE条件已验证，首次执行建议加上LIMIT，分批删除，降低锁表和主从延迟风险。

• 例如：DELETE FROM logs WHERE created_at
• 配合循环脚本或定时任务，每次删完检查影响行数、慢查询日志、主从同步状态
• MySQL 8.0+ 支持DELETE ... ORDER BY ... LIMIT，可控制删除顺序（如按主键升序）

开启事务 + 手动提交：给自己留后悔药

在支持事务的引擎（如InnoDB）中，所有DELETE都应在显式事务内执行。

• 标准流程：BEGIN; DELETE ... ; SELECT ROW_COUNT(); -- 确认数量；COMMIT; -- 或 ROLLBACK;
• 禁止依赖自动提交（autocommit=1），尤其在命令行或某些客户端工具中容易忽略
• DBA或运维平台应默认关闭生产库的autocommit，并强制要求BEGIN/COMMIT包裹变更语句

权限与环境隔离：从源头防误删

技术手段之外，规范依赖权限设计和环境管控。

• 生产库账号禁用DELETE权限，仅开放给指定运维账号；日常开发使用只读账号
• 测试库数据需定期脱敏同步，确保DELETE测试能在接近生产的环境下验证逻辑
• 上线SQL脚本必须经SQL审核平台扫描（检测无WHERE、全表删、高危关键词等），通过后才允许执行

基本上就这些。删数据不是写代码，没有“运行一下看看”的余地。多一次SELECT，多一个BEGIN，少一次背锅。