DELETE 语句的基本写法和安全前提
不加
WHERE的
DELETE FROM table_name会清空整张表，且无法回滚（除非在事务中且未提交）。生产环境执行前必须确认条件是否精确匹配目标行，否则数据丢失不可逆。 永远先用
SELECT验证：比如要删用户表中状态为 0 的记录，先运行
SELECT * FROM users WHERE status = 0 LIMIT 10确保有主键或唯一索引字段参与条件，避免误删多行 高并发场景下，
DELETE可能触发行锁甚至间隙锁，影响其他查询性能
带 WHERE 条件的 DELETE 实例与常见错误
最常出错的是条件写错、类型隐式转换、NULL 判断失效。例如：
DELETE FROM orders WHERE user_id = 'abc123';
如果
user_id是
BIGINT类型，MySQL 会把字符串强制转成数字，结果变成
user_id = 0，可能误删大量数据。 用
IS NULL判断空值，别用
= NULL（永远返回 false） 时间范围删除时注意时区：比如
created_at 在 UTC 和 CST 下含义不同批量删大量数据建议分页，用
LIMIT控制单次删除行数，避免长事务和锁表：
DELETE FROM logs WHERE created_at
TRUNCATE 和 DROP 不是 DELETE 的替代方案
TRUNCATE TABLE虽快，但它是 DDL 操作：重置自增 ID、释放磁盘空间、不可回滚、不走 binlog（某些模式下），且不能带
WHERE。而
DROP TABLE直接删表结构，不是删数据。 只想要清空表且不需要回滚 → 用
TRUNCATE，但确认无外键依赖 需要按条件删、要 binlog 记录、要事务控制 → 必须用
DELETE没加
WHERE却用了
DELETE？立刻查
SHOW PROCESSLIST看是否还在执行，必要时
KILL连接
删除后如何验证是否生效
别只信返回的 “Affected rows”，它可能显示 0 即使 SQL 语法正确——比如条件没匹配到任何行，或者被触发器拦截。
删完立刻SELECT COUNT(*)对比，尤其注意
COUNT(*)和
COUNT(非空列)区别 检查
information_schema.INNODB_TRX确认没有残留事务锁住相关行 如果启用了
binlog_format = ROW，可用
mysqlbinlog查看实际删除了哪些主键值
真正危险的不是不会写 DELETE，而是删之前没想清楚 WHERE 条件在索引上的实际执行路径，以及它会不会意外命中不该动的行。
