DELETE语句必须带精确WHERE条件，否则会清空整表且不可逆；务必先用SELECT验证、避免隐式转换和NULL误判、分批删除大数据量、区分TRUNCATE/DROP适用场景，并删后校验结果。
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 条件在索引上的实际执行路径，以及它会不会意外命中不该动的行。
