DELETE语句必须带WHERE条件，否则会清空整张表；默认逐行删除，不重置自增ID；漏写WHERE将导致数据全删且无法回滚；安全做法是先用SELECT验证条件。
DELETE 语句必须带 WHERE 条件，否则会清空整张表
MySQL 的 DELETE 默认是逐行删除，不支持像 TRUNCATE 那样快速重置自增 ID。最常踩的坑是漏写 WHERE —— 一旦执行 DELETE FROM users;，所有数据立刻丢失且无法回滚（除非有备份或 binlog）。
安全操作习惯：
- 执行前先用
SELECT验证条件：SELECT * FROM orders WHERE status = 'cancelled' AND created_at < '2023-01-01';
- 生产环境建议加上
LIMIT 1或LIMIT 100防误删过多 - 确认有开启二进制日志（
log_bin=ON），必要时可用mysqlbinlog恢复
删除单条数据：靠主键或唯一字段精准定位
删除单条本质是让 WHERE 条件匹配唯一一行。推荐用主键（如 id）或业务唯一键（如 order_no），避免因索引缺失导致全表扫描。
示例（安全写法）：
DELETE FROM products WHERE id = 12345 LIMIT 1;
注意点：
-
LIMIT 1不是冗余——即使id是主键，加它可防止 SQL 注入拼接出多条件时意外删多行 - 如果用非索引字段（如
name = 'iPhone'）且该字段重复，可能误删多条，务必先查重：SELECT COUNT(*) FROM products WHERE name = 'iPhone'; - InnoDB 下，即使只删一行，也会对整行加
X 锁，高并发时可能阻塞其他事务
删除多条数据：WHERE 条件 + LIMIT 控制影响范围
批量删除的核心矛盾是「效率」和「安全」：条件太宽易误删，不加限制可能锁表太久触发超时或主从延迟。
典型场景与写法：
- 按时间范围清理旧数据：
DELETE FROM logs WHERE created_at < '2022-01-01' LIMIT 10000;
（分批删，避免长事务）
- 按关联状态删（如用户注销后删其订单）：
DELETE o FROM orders o INNER JOIN users u ON o.user_id = u.id WHERE u.status = 'deleted' LIMIT 500;
- 用子查询需谨慎：
DELETE FROM table1 WHERE id IN (SELECT id FROM table2 WHERE ...)在 MySQL 5.7+ 会报错，应改写为JOIN形式
DELETE 后自增 ID 不重用，磁盘空间不一定立即释放
这是最容易被忽略的底层行为：
-
DELETE只是标记数据为“可覆盖”，InnoDB 的ibdata1文件大小不会缩小，auto_increment值也不会倒退 - 想真正回收空间，得执行
OPTIMIZE TABLE table_name;（会锁表，建议低峰期） - 如果只是临时清理少量数据，更轻量的做法是用
UPDATE SET deleted = 1软删除，配合查询过滤