PHP软删除技巧：is_del字段使用方法

PHP中的软删除远不止简单添加一个is_del字段——它是一场涉及数据库设计、ORM行为重写、全链路查询约束、索引优化及历史数据治理的系统性工程；手动漏判is_del会导致敏感数据泄露、统计失真和缓存污染，而强行用is_del替代Laravel原生SoftDeletes更会破坏delete/restore等核心功能；真正可靠的软删除要求全局过滤机制、字段初始化、联合索引加持，以及对SQL拼接、JOIN、COUNT、缓存、定时任务、ES同步等所有数据触点的彻底改造。

PHP 软删除为什么不能只加 is_del 字段就完事？

加一个 is_del 字段只是软删除的起点，不是终点。直接在所有查询里手动加 WHERE is_del = 0 极易遗漏，尤其在关联查询、统计、分页或第三方库调用时。一旦漏写，用户就能看到“已删除”数据，或者误删未标记的数据。

怎么让 Laravel 的 Eloquent 自动过滤软删除记录？

Laravel 原生支持软删除，但必须用 SoftDeletes trait + deleted_at 字段，而不是自定义 is_del。强行用 is_del 会导致 delete() 不生效、restore() 报错、withTrashed() 失效——因为框架底层只识别 deleted_at。

如果你必须用 is_del（比如 legacy 表结构不允许改字段），就得手动重写模型行为：

class User extends Model
{
    protected $casts = [
        'is_del' => 'boolean',
    ];
public function scopeActive($query)
{
    return $query->where('is_del', false);
}

public function delete()
{
    $this->is_del = true;
    return $this->save();
}
}

使用时必须显式调用：User::active()->find(123)，否则 User::find(123) 仍会查出已“删除”的记录。

MySQL 查询中漏掉 is_del = 0 的典型场景

• 原始 SQL 拼接：比如 "SELECT * FROM user WHERE id = {$id}" 完全没判断 is_del
• JOIN 查询：左表加了条件，右表没加，导致“已删除用户”的订单仍被查出来
• COUNT 统计：写 SELECT COUNT(*) FROM user 得到的是总行数，不是有效用户数
• 缓存键未包含 is_del 状态：缓存了含已删除数据的结果，后续请求一直读脏数据

硬切换到软删除时最常踩的坑

已有线上数据，is_del 字段默认值是 NULL 或 1，会导致历史数据全被当成“已删除”。必须在加字段后立刻执行初始化：

ALTER TABLE `user` ADD COLUMN `is_del` TINYINT(1) DEFAULT 0 NOT NULL;
UPDATE `user` SET `is_del` = 0 WHERE `is_del` IS NULL;

另外，所有索引都要重新评估——如果高频查询都带 is_del = 0，建议把 is_del 加进联合索引，例如：INDEX idx_status_id (is_del, id)。否则 MySQL 可能全表扫描过滤掉大量已删除记录。

真正麻烦的不是加字段，而是让所有读写路径都意识到这个字段的存在。哪怕 ORM 层封装好了，原生 SQL、定时任务、数据分析脚本、ES 同步逻辑，都得逐个对齐。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~