MySQL安全模式禁止无索引WHERE的DELETE/UPDATE，需SET SQL_SAFE_UPDATES=0临时关闭；删0行主因条件不匹配，应先SELECT验证；大批量删除须分批限流；误删恢复依赖ROW格式binlog或物理备份。
DELETE 语句被拒绝：You are using safe update mode
MySQL 启用了 SQL_SAFE_UPDATES 模式时，直接执行 DELETE FROM table_name 或 UPDATE table_name SET col=...（不带 WHERE 条件，或 WHERE 中未使用索引列）会报错：You are using safe update mode and you tried to update a table without a WHERE that uses a KEY column。
这不是权限或语法错误，而是 MySQL 的安全保护机制，防止全表误删/误改。默认在某些客户端（如 MySQL Workbench、mysql 命令行启用 --safe-updates）中开启。
- 临时关闭：执行
SET SQL_SAFE_UPDATES = 0;，之后再运行你的DELETE语句（当前会话生效） - 恢复保护：执行
SET SQL_SAFE_UPDATES = 1; - 命令行启动时禁用：用
mysql --safe-updates=0 -u root -p连接 - 注意：关闭后务必确认
WHERE条件写对了，否则可能删错数据
DELETE 返回 0 行影响但没报错，数据却没删掉
常见于 WHERE 条件匹配不到任何行，比如字段类型隐式转换、NULL 判断写错、时间格式不匹配等。MySQL 不报错，只是“成功删了 0 行”。
排查重点：
- 检查
WHERE中的字段是否为NULL：用IS NULL而不是= NULL - 字符串比较注意空格和大小写：字段是
VARCHAR且启用了utf8mb4_0900_as_cs等区分大小写的排序规则时，WHERE name = 'John'不会匹配'john' - 时间字段慎用字符串：例如
created_at = '2024-01-01'可能因精度丢失不匹配，建议用BETWEEN或显式转成 datetime：DATE(created_at) = '2024-01-01' - 用
SELECT COUNT(*)先验证条件：SELECT COUNT(*) FROM users WHERE status = 'inactive' AND deleted_at IS NULL;
结果为 0？那DELETE当然不删任何行
删除大量数据卡住或超时
一次性删几百万行容易锁表、打满 I/O、触发 max_execution_time 限制，甚至导致主从延迟飙升。
稳妥做法是分批删除：
- 加主键或索引列做范围切割，例如按
id：DELETE FROM logs WHERE id BETWEEN 1000000 AND 1010000 LIMIT 10000;
- 每次删完加
SLEEP(0.1)（应用层控制），避免冲击太大 - 避免用
ORDER BY+LIMIT删除（如DELETE ... ORDER BY id LIMIT 1000），MySQL 5.7+ 不支持该语法；可改用子查询或临时表 - 考虑用
pt-archiver工具，它专为归档/删除大表设计，自带限流、事务控制和进度反馈
误删后如何快速恢复
没有备份或 binlog 的情况下基本无法还原。真正可行的路径只有两条：
- 如果开启了
binlog且格式为ROW，可用mysqlbinlog解析出反向 SQL（需定位到误操作前的 position）：mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000001 | grep -A 5 -B 5 "DELETE FROM your_table"
- 从最近一次物理备份（如
mysqldump或xtrabackup）恢复，再重放备份点之后的 binlog（前提是你有完整 binlog 链） - 线上环境强烈建议：日常开启
binlog_format = ROW+expire_logs_days = 7，并定期校验备份有效性
安全模式不是挡路石，是提醒你再看一眼 WHERE 条件；而真正让人手抖的，从来不是报错，是静悄悄删掉 0 行后你以为删成功了。
