PHP实现逻辑删除表设计｜软删建表方法

MySQL建表时添加deleted_at字段实现逻辑删除，推荐datetime类型并配合复合索引；PHP中应通过ORM全局作用域或DAO层统一注入WHERE deleted_at IS NULL条件，确保读写一致性。

MySQL建表时如何添加逻辑删除字段

逻辑删除不是真删数据，而是用一个字段标记“已删除”状态。最常用的是 deleted_at（datetime 类型，NULL 表示未删）或 is_deleted（tinyint(1)，0/1）。推荐前者，兼容 Laravel、ThinkPHP 等主流框架的软删机制。

建表时直接加上该字段即可，无需额外索引——但若高频查询“未删除数据”，建议为 deleted_at 加复合索引，比如和 created_at 组合。

CREATE TABLE `users` (
  `id` bigint unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(255) NOT NULL,
  `email` varchar(255) NOT NULL,
  `deleted_at` datetime NULL DEFAULT NULL,
  `created_at` datetime DEFAULT CURRENT_TIMESTAMP,
  `updated_at` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  KEY `idx_deleted_created` (`deleted_at`, `created_at`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

PHP中如何统一实现软删查询条件

手动在每个 WHERE 后加 AND deleted_at IS NULL 容易遗漏。更可靠的方式是封装基础查询方法，或使用 ORM 的全局作用域。

• Laravel 中重写模型的 boot 方法，调用 withoutGlobalScopes() 可临时绕过软删
• 原生 PDO 或 MySQLi 查询前，统一拼接 WHERE deleted_at IS NULL 条件（注意已有 WHERE 时用 AND 连接）
• 如果用自定义 DAO 层，可在 find()、findAll() 等方法内部自动注入该条件

执行软删时为什么不能只改 deleted_at

单纯执行 UPDATE users SET deleted_at = NOW() WHERE id = ? 是对的，但容易忽略两点：

• 事务一致性：如果关联表（如订单、日志）也需要软删，必须在同一个事务里更新，否则出现“用户已删但订单还可见”
• 触发器冲突：若表上有 BEFORE UPDATE 触发器修改了 updated_at，要确认它不会覆盖或干扰 deleted_at 的赋值逻辑
• 缓存失效：Redis 或 APCu 中缓存的该记录需同步清除，否则后续读取仍返回旧数据

恢复软删数据要注意什么

恢复即把 deleted_at 设为 NULL，但别只写 SET deleted_at = NULL 就完事：

• 检查是否允许恢复：有些业务要求“删除后不可逆”，需前置校验 is_recoverable 字段或时间窗口（如仅支持 7 天内恢复）
• 更新时间戳：应同时更新 updated_at，体现恢复动作发生时间
• 关联恢复：如果该记录曾触发过级联软删（如用户删则清空其地址），恢复时未必需要反向操作——得看业务语义，多数场景下地址记录保持“已删”更安全

软删真正难的不是字段怎么建，而是所有读写路径是否都严格遵守“查前过滤、删即标记、恢须审慎”这三条线。漏掉一个地方，数据状态就可能错乱。