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软删除，配合查询过滤
