Db::delete()批量删过期数据最稳，Model::destroy()会触发事件、验证和关联操作，易卡死或漏删；清理任务应绕过业务逻辑链，直接执行SQL。
用 Db::delete() 批量删过期数据，别用 Model::destroy()
直接执行 SQL 删除最稳，Model::destroy() 会触发事件、验证、关联操作，一删几百条可能卡死或漏删。清理任务本质是“后台甩手干脏活”，不该走业务逻辑链。
常见错误现象：Model::destroy(['where' => ['expire_time' => [' 返回 0 却没报错——其实是触发了软删除判断或事件中断了流程。
-
Db::name('user_log')->where('created_at', 'delete()是安全的起点 - 务必在
where条件里加索引字段（如created_at或expire_time），否则全表扫描，大表直接锁表 - 避免用
find()+delete()循环，10 万条记录会生成 10 万个查询和模型实例
定时任务里加事务和分页删除，防锁表和超时
ThinkPHP 的命令行任务（php think clean:expired）默认无超时保护，单次删太多会卡住队列、拖垮数据库连接。
使用场景：日志表、缓存表、临时订单表，数据量 >10 万条时必须分片。
立即学习“PHP免费学习笔记（深入）”；
- 用
limit控制每次最多删 1000 条：Db::name('cache')->where('expire_time', 'limit(1000)->delete() - 删完检查影响行数，
if (Db::getRealSql() && $affected === 0) break;防无限循环 - 不建议包
transaction—— 删除本身是原子操作，加事务反而延长锁持有时间
注意 MySQL 的 safe_update 和 sql_mode 导致删除失败
很多生产环境开了 STRICT_TRANS_TABLES 或 NO_ZERO_DATE，如果过期字段是 datetime DEFAULT '0000-00-00 00:00:00'，WHERE expire_time 可能被 MySQL 拒绝执行。
错误信息典型表现：Invalid datetime format 或直接返回空结果但无提示。
- 先查下字段实际值：
SELECT COUNT(*) FROM table WHERE expire_time = '0000-00-00 00:00:00'; - 删之前补一个兜底条件：
->whereOr('expire_time', 'exp', "''")或用IS NULL判断 - 上线前在测试库执行
SELECT @@sql_mode;确认是否含严格模式
清理脚本别放 app/command 就完事，要加锁和日志标记
服务器多实例或容器重启后，可能多个进程同时跑同一个清理命令，重复删或互相干扰。
性能影响：没锁的脚本在高并发调度下，可能把同一批数据删两次，也可能因条件重叠漏删。
- 用文件锁最简单：
file_put_contents(RUNTIME_PATH . 'clean_expired.lock', time(), LOCK_EX)，删完unlink() - 每轮删除后记日志：
trace("clean_expired: deleted {$affected} rows before " . date('Y-m-d')); - 别依赖
Cron的间隔精度——加个随机延迟（如sleep(rand(0, 30))）避免集群雪崩
真正麻烦的不是写几行 delete，而是删的时候有没有人正在查这张表、索引是不是失效了、凌晨两点 DBA 正在备份——这些不会报错，但会让你的“自动清理”变成半夜告警源头。
