先说结论：SQL子查询本身就是一个筛选工具，它没法直接“清理”URL，只能帮你把那些疑似无效的链接标记出来。真正的清理动作，必须靠UPDATE或DELETE语句来完成——而且前提是，你得先用外部工具验证过这些链接是否真的失效。否则，手一抖删错数据，哭都来不及。
直接说结论：SQL子查询本身不能清理URL，只能识别无效链接；真正清理必须配合UPDATE或DELETE语句，且需先验证有效性——否则极易误删。
为什么不能只靠SELECT子查询就“清理”
很多人有个错觉：写个SELECT查出所有返回404的URL，就觉得已经“清理”过了。实际上，连一行数据都没动。子查询（比如WHERE id IN (SELECT ...)）只是定义了一个筛选逻辑，它不碰数据。
- 真正的清理，必须是
DELETE FROM table WHERE id IN (SELECT id FROM ...)或UPDATE table SET status = 'invalid' WHERE ...这类写入操作。 - 问题在于，你在子查询里判断“无效”的依据往往不靠谱。数据库没法发起HTTP请求，靠
LIKE '%404%'或者url IS NULL这样的文本条件，很容易漏判或误判。 - 没有外部校验（比如用Python脚本批量
HEAD请求验证）就直接执行DELETE，风险高到离谱。
安全清理的三步实操流程
把“识别→验证→清理”拆开来做，别指望一步到位。
- 第一步：导出待验证URL列表。用
SELECT id, url INTO OUTFILE '/tmp/urls_to_check.txt'（MySQL）或COPY (SELECT id, url FROM links WHERE status != 'valid') TO '/tmp/urls_to_check.csv'（PostgreSQL），把结果扔给外部脚本处理。 - 第二步：用外部工具验证有效性。比如Python +
requests.head()，跑一轮下来，生成两份文件：valid_ids.csv和invalid_ids.csv。 - 第三步：用子查询驱动清理。例如：
DELETE FROM links WHERE id IN (SELECT id FROM invalid_ids_temp);
注意：invalid_ids_temp必须是已经导入数据库的临时表，不能直接读文件。
NOT EXISTS比NOT IN更适合排除无效链接
当你想要保留那些“有对应有效访问记录”的URL时，NOT IN有个大坑：如果子查询结果里包含NULL，整个WHERE条件会直接失效（返回空集）。而NOT EXISTS就不会有这个问题。
- 错误写法：
WHERE url NOT IN (SELECT url FROM http_logs WHERE status_code = 404)—— 一旦http_logs.url里有NULL，这条WHERE等于白写。 - 推荐写法：
WHERE NOT EXISTS (SELECT 1 FROM http_logs l WHERE l.url = links.url AND l.status_code = 404)
- 性能方面，给
http_logs(url, status_code)建一个联合索引，能明显加快子查询的速度。
说到底，写子查询本身并不难。真正的难点在于定义清楚“无效”到底是什么——是DNS解析失败？连接超时？还是HTTP 4xx/5xx？这些边界条件必须在外部验证阶段就明确下来，数据库只负责忠实地执行你已经确认过的决策。
