防止误删MySQL数据需多层防护：禁直连生产库、强制工单审核、DBA账号双因素认证、SQL安全模式、删除前先查后删并保存条件快照。
防止误删 MySQL 数据，核心是“多一层防护、少一次直连、加一次确认”。不依赖事后恢复，而是在操作前就切断高危路径。
禁止直接在生产环境执行 DELETE 或 DROP
生产库应默认关闭 root 或高权限账号的远程登录，且严禁用图形化工具（如 Navicat、DBeaver）或命令行直接连接生产库执行删除类语句。所有变更必须走工单+SQL审核流程。
- 开发/运维人员只允许访问测试库，生产库仅开放给 DBA 或自动化平台账号
- DBA 账号启用双因素认证，并限制 IP 白名单和登录时段
- 任何 DELETE / DROP / TRUNCATE 操作，必须附带 WHERE 条件（且 WHERE 必须含主键或唯一索引字段），否则 SQL 审核自动拦截
开启安全模式（sql_safe_updates）
在会话级或全局启用 sql_safe_updates=1，可强制要求 UPDATE 和 DELETE 必须带 WHERE 条件，或 WHERE 中必须使用索引字段，避免全表扫描式误删。
- 临时启用：SET SQL_SAFE_UPDATES = 1;
- 永久生效：在 my.cnf 的 [mysqld] 段添加 sql_safe_updates=1，重启或动态设置（需 SUPER 权限）
- 注意：该参数不影响 DROP/TRUNCATE，仍需靠权限和流程控制
删除前先查后删，且保留原始条件快照
把“DELETE”拆成两步：“SELECT COUNT(*) + SELECT * LIMIT 10”验证范围，再执行删除。关键是要把验证用的 WHERE 条件单独保存，避免复制粘贴出错。
- 示例流程：
SELECT COUNT(*) FROM orders WHERE status = 'cancelled' AND created_at
SELECT id, status, created_at FROM orders WHERE status = 'cancelled' AND created_at
确认无误后再执行：
DELETE FROM orders WHERE status = 'cancelled' AND created_at - 建议用脚本封装该流程，或使用支持“预览删除行”的 CLI 工具（如 mycli 启用 auto-vertical-output）
定期备份 + 开启 binlog + 限制 purge 权限
备份不是为了“能恢复”，而是为了“敢操作”。binlog 是误删后精准回滚的最后防线，但前提是它存在且没被误删。
- 全量备份每日一次（如 mysqldump 或 xtrabackup），binlog 保留至少 7 天
- 关闭普通账号的 PURGE BINARY LOGS 权限，防止误清日志
- binlog_format 必须为 ROW（而非 STATEMENT），才能支持基于行的闪回（如 mysqlbinlog 解析 + 反向生成 INSERT/UPDATE）
- 测试环境定期演练恢复流程：从备份 + binlog 恢复到误删前一秒
