php删除数据怎么逻辑删除_标记状态代替物理删除【说明】

逻辑删除是通过 status 字段标记删除状态而非物理删除，所有查询必须加 status = 1 过滤，UPDATE 替代 DELETE，建议用 TINYINT(1) 或 ENUM 类型并加索引，需记录 deleted_at 并校验恢复操作。

PHP 中用 status 字段实现逻辑删除

直接删掉数据库记录是物理删除，风险高、不可逆；逻辑删除只是把 status 字段设为已删除状态（比如 0 或 'deleted'），后续查询时过滤掉这些记录。这是 PHP 项目里最常用、也最稳妥的软删除方案。

WHERE 条件里必须始终带上 status 过滤

一旦用了逻辑删除，所有读取数据的 SQL 都得默认排除已标记删除的行，否则用户会看到“不该看到的数据”。漏加 WHERE status = 1 是最常见、也最危险的疏忽。

• 列表页、详情页、关联查询，全部要检查是否加了 status = 1
• 使用 ORM（如 Laravel Eloquent）可全局作用域自动处理，但原生 PDO 或 MySQLi 必须手动写
• 别依赖前端传来的 id 做唯一判断——攻击者可能传一个 status = 0 的 ID，后端没校验就返回数据

SELECT id, title FROM articles WHERE status = 1 AND id = ?

UPDATE 语句代替 DELETE 语句

原来写 DELETE FROM users WHERE id = ? 的地方，现在统一改成 UPDATE 更新状态字段。注意：不要用 INSERT ... ON DUPLICATE KEY UPDATE 或触发器模拟删除，那会增加复杂度和出错概率。

• 状态字段类型建议用 TINYINT(1)（值 0/1）或 ENUM('active','deleted')，避免用字符串如 'disabled' 增加拼写错误风险
• 给 status 字段加索引，尤其当表数据量大、又频繁按状态筛选时
• 如果业务需要区分“已删除”“已归档”“已冻结”，就用多值枚举或整型状态码，但务必配好文档和常量定义

UPDATE orders SET status = 0, deleted_at = NOW() WHERE id = ? AND status = 1

真实场景中容易被忽略的细节

逻辑删除不是加个字段就完事，很多坑藏在边界里：

• deleted_at 字段建议一并记录，用于审计或后期清理，且能辅助判断“是否真删过”
• 外键关联表（如评论、日志）要不要同步更新状态？通常不级联，而是查主表时 LEFT JOIN 并加主表状态条件
• 管理员后台“恢复删除”功能，本质就是 UPDATE ... SET status = 1，但必须校验原记录确实存在且当前是已删除态
• 搜索、导出、统计类接口最容易漏掉 status 过滤，特别是导出全量数据时，默认不能包含已删除项

状态字段本身不难，难的是整个系统所有数据流都对它保持一致认知——哪怕一个接口忘了加 status = 1，就等于逻辑删除形同虚设。