DELETE语句必须带WHERE条件，否则会静默清空整张表；建议先用SELECT验证条件，大表删除应避免直接DELETE以防卡顿锁表。
DELETE 语句必须带 WHERE，否则会清空整张表
MySQL 的 DELETE 默认不加条件就是删全表，不是“删不掉”或“报错”，而是静默执行——这是线上事故最高发的操作之一。你执行 DELETE FROM users;，只要权限够，立刻删光所有记录，连事务回滚都救不回来（除非开了 binlog 且能闪回）。
实操建议：
- 任何
DELETE前，先用SELECT验证条件：比如要删 2023 年前的订单，先跑SELECT * FROM orders WHERE created_at - 开发/测试环境开启
SQL_SAFE_UPDATES=1（在 MySQL 配置或会话中设置），它会拒绝没带主键或索引字段的 WHERE 条件的 DELETE/UPDATE - 生产环境严禁直接在命令行或 Navicat 里手敲 DELETE，应走带审批的 SQL 工单系统，且自动校验 WHERE 是否含索引列
WHERE 条件写错导致误删，常见于字符串和 NULL 判断
比如想删用户名为空的用户，写成 DELETE FROM users WHERE name = '' 看似合理，但实际可能漏掉 name IS NULL 的记录；反过来，若写成 WHERE name IS NULL 又会漏掉空字符串。这两者在 MySQL 中完全不等价。
实操建议：
- 明确字段是否允许 NULL：用
SHOW CREATE TABLE users;查看name定义，是NOT NULL DEFAULT ''还是NULL - 安全写法是合并判断：
WHERE name = '' OR name IS NULL（注意 OR 优先级，必要时加括号） - 日期字段别信直觉：
created_at 实际等价于 <code>created_at ，但如果你本意是“2024 年及之后”，就得写 <code>created_at >= '2024-01-01'
大表删除卡顿、锁表、影响业务，别直接 DELETE
删几万行以上，尤其在高并发写入的表上，DELETE FROM logs WHERE ts 会持有行锁甚至表锁，拖慢其他查询，还可能触发 long transaction 报警。
实操建议：
- 分批删：用
WHERE id BETWEEN ? AND ?或LIMIT控制每次删 1000 行，例如：DELETE FROM logs WHERE ts ，循环执行直到影响行为 0 - 用主键范围比时间戳更稳定：时间字段若无索引或有重复值，ORDER BY + LIMIT 可能跳过或重复删
- 考虑归档替代删除：把旧数据 INSERT INTO archive_table SELECT ...，再 DROP PARTITION（如果用了分区表）或 TRUNCATE 分区，比逐行 DELETE 快一个数量级
TRUNCATE 和 DROP 不是 DELETE 的快捷方式，它们不可回滚且重置自增
TRUNCATE TABLE users; 看起来像“清空”，但它不是 DML 而是 DDL，不走事务日志，不能被 ROLLBACK，还会重置 AUTO_INCREMENT 计数器。有些 ORM 框架（如 Django 的 truncate 方法）底层就调这个，容易踩坑。
实操建议：
- 只在确定要彻底清空、且后续插入从 1 开始时才用
TRUNCATE；日常清理数据一律用DELETE -
DROP TABLE更危险：删表同时删元数据，连表结构都没了，除非你在做重建库或测试初始化 - 注意存储引擎差异：InnoDB 支持
TRUNCATE回滚（仅限事务内），但 MySQL 8.0+ 才支持；MyISAM 则完全不可回滚
真正麻烦的从来不是语法写对没，而是 WHERE 条件是否覆盖全、索引是否生效、删的量级是否可控——这些没法靠一条命令解决，得结合 EXPLAIN、slow log 和监控一起看。
