SQL子查询本身不能清理URL，只能识别无效链接；真正清理必须配合UPDATE或DELETE语句，且需先通过外部工具验证有效性，否则极易误删。
直接说结论：SQL子查询本身不能清理URL，只能识别无效链接；真正清理必须配合UPDATE或DELETE语句，且需先验证有效性——否则极易误删。
为什么不能只靠SELECT子查询就“清理”
子查询（比如WHERE id IN (SELECT ...)）只是数据筛选逻辑，它不修改数据。常见误解是写个SELECT查出“404 URL”，就以为完成了清理——其实连一行都没动。
- 真实清理动作必须是
DELETE FROM table WHERE id IN (SELECT id FROM ...)或UPDATE table SET status = 'invalid' WHERE ... - 子查询里判断“无效URL”的依据往往不可靠：数据库无法发起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时会整个失效（返回空集），而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？这些边界条件必须在外部验证阶段明确，数据库只负责执行你确认过的决策。
