怎么通过 SQL 的 DELETE 语句配合 WHERE 条件删除数据库中的无效数据

说实话，用 DELETE 配合 WHERE 删数据这事儿，看似简单，翻车案例可一点不少。说到底，核心就一句话：先确认、再删除、有回退。语法真不复杂，复杂的是你得把条件写准了，还得保证删得安全。

哪几类数据算是“无效数据”？

无效数据不是凭感觉就能定的，它得能用字段值说清楚。常见的几种，基本跑不出下面这几类：

• 状态值直接告诉你“废了”。比如 status = 'inactive'、discontinued = 1，这明摆着就是已停用、已作废的记录。
• 时间字段早就过期了。典型场景是清理两年没登录的账号，或者清理2020年之前的订单，写法就是 created_at < '2020-01-01' 或 last_login < DATE_SUB(NOW(), INTERVAL 2 YEAR)。
• 关联字段是断线的。比如 user_id 在主表里根本查不到，自然就是孤魂野鬼了。
• 业务上明确定义为异常的值。比如 price < 0 这种明显不合常理的数据，或者 email 连个 @ 都没有的记录。

标准操作流程：三步走，一步都别省

第一步：先跑 SELECT，确认 WHERE 条件打在谁身上
别急着敲 DELETE，先拿同样的条件跑一条 SELECT 看看。目标数据对不对，数量对不对，一眼就能确认。这一步是兜底的。

SELECT * FROM orders WHERE status = 'cancelled' AND created_at < '2022-01-01';

第二步：在事务里执行 DELETE
确认无误后，把 DELETE 包进事务里。这样万一删错了、删多了，一个 ROLLBACK 就能救回来，不用拍大腿后悔。

START TRANSACTION;
DELETE FROM orders WHERE status = 'cancelled' AND created_at < '2022-01-01';
-- 检查影响行数，没问题再提交
COMMIT;

第三步：备份与留痕
删之前最好把数据导出来存一份，至少保留7天。同时把删除语句、执行时间、影响行数都记到日志里。事后追查时，这就是证据。

几个常见的坑，得绕着走

• 别一次删大表里的旧数据。几百万行数据一把反赌，锁表是小事，拖垮线上服务才是大事。正确的做法是分批删，每次加 LIMIT 和 ORDER BY，循环执行直到影响行为 0：
  DELETE FROM logs WHERE created_at < '2021-01-01' ORDER BY id LIMIT 10000;
• 同表子查询在 MySQL 里是禁地。MySQL 不允许 DELETE 的子查询直接引用目标表。比如要删 goods_show 里没有对应 goods 的记录，不能直接写 IN (SELECT ... 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);
• 外键约束必须查清楚。删主表数据时，如果子表设置了 ON DELETE RESTRICT，会直接报错不让删；如果设了 CASCADE，会连带删掉子表的数据——很可能不是你想要的结果。动手前先把约束定义看明白。

一个更稳妥的选择：软删除

对于核心业务表，建议优先考虑软删除。说白了就是不真删，只是更新一个标记字段。

UPDATE users SET is_deleted = 1, deleted_at = NOW() WHERE last_login < '2020-01-01';

之后所有查询都加上 AND is_deleted = 0 的条件过滤。这样既释放了“逻辑上”的无效数据，又保留了完整恢复的能力，也避免了触发器或级联删除带来的连锁反应。