清孤儿数据需先甄别真孤儿再分层清理，禁用Model::destroy()等高开销方式，改用LEFT JOIN+IS NULL识别并Db::delete()批量删除，控制limit防锁表，删文件须双向比对且dry-run校验。
清孤儿数据不是“删完就完”，而是要先确认哪些是真孤儿、哪些只是暂时没被查到，再分层清理。直接用 Model::destroy() 或 Db::delete() 乱扫，大概率漏删、误删、卡死，甚至触发软删除逻辑导致“删了但还在”。
怎么识别真正的孤儿记录（比如 orphaned user_log）
孤儿的本质是：外键字段值在关联主表中不存在，或该字段为 NULL/空字符串但业务上不允许。不能只靠 WHERE user_id NOT IN (SELECT id FROM user) —— 子查询在大表上会极慢，且 MySQL 对 NOT IN 中含 NULL 的结果有陷阱行为（整条结果变空）。
- 推荐用
LEFT JOIN+IS NULL：Db::name('user_log')->alias('l')->field('l.id')->join('user u', 'l.user_id = u.id', 'LEFT')->where('u.id', 'null')->select() - 若外键允许
0或空字符串，需额外补条件：->whereOr('l.user_id', 0)->whereOr('l.user_id', '') - 务必在
user_id字段建索引，否则 JOIN 扫全表，10 万行以上基本卡住
批量删孤儿时为什么不能用 Model::destroy()？
Model::destroy() 会逐条实例化模型、触发 before_delete、验证、关联删除、事务钩子——对 5 万条孤儿日志，等于生成 5 万个 PHP 对象，内存爆、超时、锁表全占齐。它适合业务侧“删一个用户并级联清掉他的评论”，不适合后台清理任务。
- 改用
Db::name('user_log')->where(...)->delete()，纯 SQL 执行，无模型开销 - 删前加
limit(1000)控制单次影响行数，防锁表：->limit(1000)->delete() - 删完检查返回值：
$affected = Db::name(...)->delete(); if ($affected === 0) break;，避免无限循环
清图片文件这类磁盘孤儿要注意什么？
数据库里删了记录，不代表磁盘上的 avatar_123.jpg 就该立刻删——可能被 CDN 缓存、被其他系统硬编码引用、或刚上传还没入库成功。必须做双向比对，且只删“确定没人用”的。
立即学习“PHP免费学习笔记（深入）”；
- 从数据库提取所有被引用的文件名（仅
basename，不要路径）：Db::name('article')->column('cover') - 用
DirectoryIterator遍历图片目录，用$file->getFilename()匹配，不是$file->getPathname() - 删除前加日志和 dry-run 开关：
if (!$dryRun) { unlink($file->getPathname()); } - 别递归删子目录，除非你明确知道所有图片都在同一层；否则容易误删配置文件或 .gitignore 外的敏感文件
TRUNCATE 表前得问自己三个问题
TRUNCATE TABLE 看似快，但它重置自增 ID、不走事务、不触发事件，一旦执行无法回滚。很多“清缓存表”场景其实不该用它。
- 是否需要保留部分历史（比如最近 7 天的 log）？→ 改用
DELETE FROM ... WHERE created_at - 表是否被其他服务实时读写？
TRUNCATE是 DDL，在 MySQL 中会隐式提交并锁表，高并发下可能阻塞写入 - 是否依赖自增 ID 连续性？比如导出报表时按 ID 排序，TRUNCATE 后新数据 ID 从 1 开始，可能和旧 ID 冲突
真正适合 TRUNCATE 的，只有那些完全无外键、无业务语义、纯临时用途的表，比如 queue_failed 或 search_cache。用之前，先跑一遍 SELECT COUNT(*) FROM table 确认数据量，别让“清空”变成“清库”。
