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 行后你以为删成功了。
