删除无效数据须先SELECT验证、再事务中DELETE、最后备份记录；无效数据需字段值明确定义，如status='inactive'或created_at<'2020-01-01'；大表分批删，避同表子查询，外键约束需查清；核心业务优先软删除。
用 DELETE 配合 WHERE 删除无效数据，核心是“先确认、再删除、有回退”。关键不在语法多复杂，而在于条件写得准不准、删得安不安全。
明确什么是“无效数据”
无效数据不是模糊概念，必须能用字段值清晰判断。常见类型包括：
- 状态字段为停用/已删除/已作废（如 status = 'inactive' 或 discontinued = 1）
- 时间字段明显过期（如 created_at < '2020-01-01' 或 last_login < DATE_SUB(NOW(), INTERVAL 2 YEAR)）
- 关联字段为空或失效（如 user_id NOT IN (SELECT id FROM users)，需注意子查询写法限制）
- 业务规则定义的异常值（如 price < 0 或 email NOT LIKE '%@%'）
标准操作流程：三步不能跳
第一步：用 SELECT 验证 WHERE 条件
永远先执行等效的 SELECT，看它真的一一对应你要删的数据：
第二步：用 DELETE 执行（建议套事务）
确认无误后，在事务中执行，方便出错立刻回滚：
DELETE FROM orders WHERE status = 'cancelled' AND created_at < '2022-01-01';
-- 检查影响行数，没问题就提交
COMMIT;
第三步：记录与备份
删除前导出这批数据（如用 mysqldump 或 SELECT INTO OUTFILE），至少保留 7 天；同时在日志里记下语句、时间、影响行数。
避开常见坑点
-
别直接删大表旧数据：一次删几百万行可能锁表、拖慢服务。可分批删，例如加 LIMIT 和 ORDER BY：
DELETE FROM logs WHERE created_at < '2021-01-01' ORDER BY id LIMIT 10000; 循环执行直到影响行为 0。 -
子查询慎用同表：MySQL 不允许 DELETE 中的子查询直接引用目标表。要删 goods_show 中无对应 goods 的记录，不能写：
DELETE FROM goods_show WHERE id IN (SELECT id FROM goods_show ...);
得改成带别名的写法：
DELETE FROM goods_show WHERE id IN (SELECT id FROM (SELECT id FROM goods_show LEFT JOIN goods ON ... WHERE goods.id IS NULL) AS tmp); - 外键约束要留意：如果删的是主表（如 users），而子表（如 orders）设置了 ON DELETE RESTRICT，会报错；设了 CASCADE 会连带删子表数据——这未必是你想要的，务必查清约束定义。
替代方案：软删除更稳妥
对核心业务表，推荐优先考虑软删除：不真正删，只更新标记字段。
UPDATE users SET is_deleted = 1, deleted_at = NOW() WHERE last_login < '2020-01-01';后续所有查询加 AND is_deleted = 0 过滤。这样既释放逻辑空间，又保留恢复能力，也避免触发器或级联带来的意外。
