如何实现数据的“软删除”？-mysql教程-PHP中文网

如何实现数据的“软删除”？

幻影之瞳

发布： 2025-09-08 12:28:01

原创

538人浏览过

软删除通过标记而非移除记录实现逻辑删除，需添加is_deleted或deleted_at字段，将DELETE转为UPDATE，并在查询时过滤已删除数据，便于审计与恢复，但会增加存储开销并影响查询性能，需结合索引、分区、清理策略优化，适用于需保留历史数据的场景，不适用于数据量大、存储敏感或要求彻底删除的场景。

如何实现数据的“软删除”？

数据的“软删除”是指在数据库中不真正删除数据记录，而是通过设置一个状态字段（例如

is_deleted

登录后复制

或

deleted_at

登录后复制

）来标记该记录为已删除。这样，在查询数据时，可以通过过滤掉这些标记为已删除的记录，从而达到逻辑上的删除效果。好处是可以保留历史数据，方便审计和恢复。

解决方案：

实现数据软删除的关键在于修改数据表结构和查询逻辑。

修改数据表结构：

在需要软删除的数据表中，添加一个用于标记删除状态的字段。常见的做法是添加一个
```
is_deleted
```
登录后复制
字段（布尔类型）或
```
deleted_at
```
登录后复制
字段（时间戳类型）。
- ```
is_deleted
```
  登录后复制
  :
```
BOOLEAN DEFAULT FALSE
```
  登录后复制
  。
```
TRUE
```
  登录后复制
  表示已删除，
```
FALSE
```
  登录后复制
  表示未删除。
- ```
deleted_at
```
  登录后复制
  :
```
TIMESTAMP NULL DEFAULT NULL
```
  登录后复制
  。如果该字段有值，表示删除时间；
```
NULL
```
  登录后复制
  表示未删除。
例如，在 MySQL 中：
```
ALTER TABLE users ADD COLUMN is_deleted BOOLEAN DEFAULT FALSE;

-- 或者

ALTER TABLE users ADD COLUMN deleted_at TIMESTAMP NULL DEFAULT NULL;
```
登录后复制
修改删除操作：

将原本的
```
DELETE
```
登录后复制
语句替换为
```
UPDATE
```
登录后复制
语句，更新删除状态字段。
- 使用
```
is_deleted
```
  登录后复制
  字段：
```
UPDATE users SET is_deleted = TRUE WHERE id = 123;
```
  登录后复制
- 使用
```
deleted_at
```
  登录后复制
  字段：
```
UPDATE users SET deleted_at = NOW() WHERE id = 123;
```
  登录后复制
在应用程序层面，也需要修改相应的删除逻辑，调用更新语句而不是删除语句。
修改查询操作：

在所有的查询语句中，添加
```
WHERE
```
登录后复制
子句，过滤掉已删除的记录。
- 使用
```
is_deleted
```
  登录后复制
  字段：
```
SELECT * FROM users WHERE is_deleted = FALSE;
```
  登录后复制
- 使用
```
deleted_at
```
  登录后复制
  字段：
```
SELECT * FROM users WHERE deleted_at IS NULL;
```
  登录后复制
这需要在应用程序的各个数据访问层进行修改，确保只查询未被标记为删除的记录。可以使用 ORM 框架提供的全局 scope 功能，自动添加这个
```
WHERE
```
登录后复制
子句。
数据恢复（可选）：

如果需要恢复已删除的数据，只需要将删除状态字段恢复到初始值即可。
- 使用
```
is_deleted
```
  登录后复制
  字段：
```
UPDATE users SET is_deleted = FALSE WHERE id = 123;
```
  登录后复制
- 使用
```
deleted_at
```
  登录后复制
  字段：
```
UPDATE users SET deleted_at = NULL WHERE id = 123;
```
  登录后复制
注意事项：
- 确保所有的数据访问都经过修改，避免遗漏，否则可能会查询到已删除的数据。
- 对于有外键约束的表，需要先更新外键表中的记录，再更新主表中的记录。
- 如果数据量很大，可以考虑对
```
is_deleted
```
  登录后复制
  或
```
deleted_at
```
  登录后复制
  字段添加索引，提高查询效率。

软删除看似简单，但实际应用中需要考虑很多细节。例如，如果某些查询逻辑依赖于已删除的数据，则需要特殊处理。

软删除会增加数据库的存储空间，因为被“删除”的数据仍然存在。所以，需要定期清理不再需要的历史数据。

软删除和物理删除的选择取决于具体的业务需求。如果数据非常重要，需要保留历史记录，那么软删除是一个不错的选择。如果数据不重要，或者存储空间有限，那么物理删除可能更合适。

如何使用 ORM 框架实现全局软删除？

大多数 ORM 框架都提供了全局 scope 的功能，可以方便地实现软删除。以 Laravel 为例：

定义一个 trait：

namespace App\Traits;

use Illuminate\Database\Eloquent\Builder;

trait SoftDeletes
{
    /**
     * Boot the soft deleting trait for a model.
     *
     * @return void
     */
    public static function bootSoftDeletes()
    {
        static::addGlobalScope('soft_deleting', function (Builder $builder) {
            $builder->whereNull('deleted_at');
        });
    }

    /**
     * Perform the actual delete query on the model instance.
     *
     * @return void
     */
    public function delete()
    {
        $this->deleted_at = $this->freshTimestamp();
        $this->save();
    }

    /**
     * Restore a soft-deleted model instance.
     *
     * @return void
     */
    public function restore()
    {
        $this->deleted_at = null;
        $this->save();
    }
}

登录后复制

在 Model 中使用 trait：

namespace App\Models;

use Illuminate\Database\Eloquent\Model;
use App\Traits\SoftDeletes;

class User extends Model
{
    use SoftDeletes;

    protected $table = 'users';
}

登录后复制

修改数据库迁移文件：

腾讯智影-AI数字人

基于AI数字人能力，实现7*24小时AI数字人直播带货，低成本实现直播业务快速增增，全天智能在线直播

查看详情

Schema::create('users', function (Blueprint $table) {
    $table->id();
    $table->string('name');
    $table->string('email')->unique();
    $table->timestamp('email_verified_at')->nullable();
    $table->string('password');
    $table->rememberToken();
    $table->timestamps();
    $table->timestamp('deleted_at')->nullable(); // Add deleted_at column
});

登录后复制

这样，所有的

User

登录后复制

模型查询都会自动添加

WHERE deleted_at IS NULL

登录后复制

的条件。删除操作也会更新

deleted_at

登录后复制

字段，而不是真正删除数据。恢复操作则将

deleted_at

登录后复制

字段设置为

NULL

登录后复制

。

软删除对数据库性能有什么影响？如何优化？

软删除本身对写操作的性能影响很小，因为只是更新一个字段。但是，对读操作的性能影响较大，因为需要在所有的查询语句中添加

WHERE

登录后复制

子句。

优化软删除对数据库性能的影响，可以从以下几个方面入手：

添加索引：

对
```
is_deleted
```
登录后复制
或
```
deleted_at
```
登录后复制
字段添加索引，可以显著提高查询效率。
```
CREATE INDEX idx_users_deleted_at ON users (deleted_at);
```
登录后复制
分区表：

如果数据量非常大，可以考虑使用分区表，将数据按照时间或其他维度进行分区。这样，可以只查询需要的分区，减少查询的数据量。
定期清理：

定期清理不再需要的历史数据，可以减少数据库的存储空间，提高查询效率。清理操作需要谨慎，确保不会误删重要数据。
使用物化视图：

对于复杂的查询，可以使用物化视图，预先计算好查询结果，并将其存储在数据库中。这样，可以避免每次查询都进行复杂的计算。
缓存：

对于经常访问的数据，可以使用缓存，减少数据库的访问次数。

软删除在什么场景下不适用？

虽然软删除有很多优点，但在某些场景下并不适用：

数据量非常大：

如果数据量非常大，软删除会占用大量的存储空间，导致数据库性能下降。在这种情况下，物理删除可能更合适。
数据不重要：

如果数据不重要，不需要保留历史记录，那么物理删除更简单、更高效。
需要严格的数据一致性：

软删除可能会导致数据不一致，例如，两个用户可以拥有相同的用户名，只要其中一个被软删除了。如果需要严格的数据一致性，那么物理删除可能更合适。
存储成本敏感：

软删除保留了所有数据，增加了存储成本。如果存储成本非常敏感，那么物理删除可能更合适。
法律法规限制：

某些法律法规可能要求必须彻底删除数据，不能保留任何备份。在这种情况下，只能使用物理删除。