DELETE WHERE 是最常用但易出错的删除方式，需确保条件准确、字段有索引、操作在事务中执行，并对大批量删除采用分批处理以避免锁表和日志膨胀。
DELETE WHERE 是最常用也最容易出错的方式
直接用 DELETE FROM table_name WHERE condition 删除符合条件的多行，是绝大多数场景下的第一选择。但它不是“删得快”就完事——错误的条件、缺失的索引、锁表风险，都会让这条语句变成线上事故源头。
常见错误现象：DELETE FROM orders WHERE status = 'cancelled' 看似安全，但如果 status 列没建索引，MySQL 或 SQL Server 会全表扫描，锁住整张表几秒甚至几分钟；更糟的是，WHERE 条件写成 status = 'canceled'（拼错），结果一条不删，还误以为清理成功。
- 执行前务必先跑
SELECT COUNT(*) FROM table_name WHERE condition确认数量 - 再用
SELECT * FROM table_name WHERE condition LIMIT 10抽样检查实际匹配的数据 - 确保 WHERE 中涉及的字段（尤其是高频过滤字段）有索引，否则删除过程可能阻塞其他查询
- 生产环境必须包裹在事务里，比如
BEGIN TRAN; DELETE ... ; -- 检查影响行数后再 COMMIT 或 ROLLBACK
大批量删（10万+行）不能只靠单条 DELETE
一次性删几十万行，DELETE 会生成巨量日志、长时间持有锁、极易触发超时或主从延迟。这时候它已不是“批量”，而是“阻塞源”。
真实使用场景：清理半年前的 log_event 表，预计 280 万行；或按时间分区删除旧订单，但表没做分区。
- 优先考虑分批删：每次删 5000 行，用
DELETE TOP (5000) FROM log_event WHERE created_at （SQL Server）或 <code>DELETE FROM log_event WHERE created_at （MySQL） - 每次删除后加
WAITFOR DELAY '00:00:00.1'（SQL Server）或SLEEP(0.1)（MySQL），缓解 I/O 和锁压力 - 避免在高峰期执行；监控
@@ROWCOUNT（SQL Server）或ROW_COUNT()（MySQL）确认每批真实影响行数 - 别信“加了 LIMIT 就安全”——MySQL 的
LIMIT在非主键排序下可能跳过或重复删，务必搭配ORDER BY 主键
TRUNCATE 不等于 “安全清空”，它绕过了很多约束
TRUNCATE TABLE table_name 确实快，但它根本不管 WHERE，也不走触发器、不记完整日志、不支持事务回滚（SQL Server 中可回滚，但 MySQL 中不可）。它适合真正要“重置表”的场景，而不是“删一部分”。
典型误用：想删掉测试环境里所有用户数据，顺手写了 TRUNCATE TABLE users，结果发现外键引用它的 user_profiles 表报错——因为 TRUNCATE 无法在有外键依赖的表上直接执行（SQL Server 报错，MySQL 5.7+ 默认也不允许）。
- 仅当你要清空整张表、且确认无外键依赖、无触发器逻辑、无需审计日志时才用
TRUNCATE - SQL Server 中它会重置
IDENTITY列，MySQL 中也会重置自增计数器，这点和DELETE本质不同 - MySQL 8.0+ 支持
TRUNCATE TABLE ... RESTART IDENTITY，但仍是全表操作，和条件无关
跨表关联删必须小心子查询写法
要用 A 表的某些记录去删 B 表对应数据，比如“删掉所有没有订单的用户”，写成 DELETE FROM users WHERE id NOT IN (SELECT user_id FROM orders) 看似合理，但在 MySQL 中，如果 orders.user_id 含 NULL，整个 NOT IN 判定会永远为 FALSE，结果一删不删。
更隐蔽的问题：SQL Server 对子查询中引用被删表名有限制，直接写 DELETE FROM t1 WHERE id IN (SELECT id FROM t1 WHERE ...) 会报错。
- MySQL 推荐改用
LEFT JOIN写法：DELETE u FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.user_id IS NULL - SQL Server 支持
DELETE FROM users WHERE id IN (SELECT user_id FROM orders GROUP BY user_id)，但必须确保子查询不返回 NULL - 任何跨表删操作，都应先用
SELECT模拟等效逻辑，验证结果集是否符合预期
真正难的不是写出能运行的 SQL，而是预判它在百万级数据、高并发、主从同步、权限隔离这些真实约束下会怎么行为。删之前那句 SELECT COUNT(*) 不是仪式，是底线。
