MyBatis-Plus逻辑删除配置全流程解析，手把手教你实现软删除功能

第一章：MyBatis-Plus逻辑删除概述

在现代企业级应用开发中，数据安全与历史记录的保留至关重要。物理删除会永久移除数据库中的记录，可能导致关键信息丢失。MyBatis-Plus 提供了逻辑删除功能，通过标记字段状态来模拟删除操作，从而实现数据的“软删除”。

逻辑删除的基本原理

逻辑删除并非真正从数据库中移除记录，而是通过更新表中的某个字段（如 deleted）来标识该数据是否已被删除。通常使用 0 表示未删除，1 表示已删除。查询时，MyBatis-Plus 会自动拦截 SQL 并添加条件过滤掉已标记删除的数据。

启用逻辑删除的配置方式

在 Spring Boot 项目中，需在配置类或 application.yml 中进行如下设置：

// 实体类中指定逻辑删除字段
@TableLogic
private Integer deleted;

# application.yml 配置逻辑删除规则
mybatis-plus:
  global-config:
    db-config:
      logic-delete-field: deleted  # 全局逻辑删除字段名
      logic-delete-value: 1        # 已删除值
      logic-not-delete-value: 0    # 未删除值

逻辑删除的优势与适用场景

• 保障数据完整性，避免误删导致的信息丢失
• 支持数据恢复，便于审计和追踪历史操作
• 适用于用户账户、订单、文章等需要保留历史记录的业务场景

下表展示了逻辑删除与物理删除的对比：

特性	逻辑删除	物理删除
数据存储	保留在数据库中	永久移除
查询性能	需过滤条件，略慢	直接减少数据量，较快
数据恢复	可恢复	不可恢复

graph TD A[执行删除操作] --> B{是否启用逻辑删除} B -->|是| C[更新deleted字段为1] B -->|否| D[执行DELETE语句] C --> E[查询时自动过滤deleted=1的记录]

第二章：逻辑删除核心概念与原理剖析

2.1 逻辑删除与物理删除的本质区别

在数据管理中，删除操作并非总是意味着彻底移除。逻辑删除与物理删除代表了两种截然不同的数据处理策略。

物理删除：彻底清除

物理删除是指从数据库中永久移除记录，数据页被回收，无法通过常规手段恢复。这种方式节省存储空间，但一旦执行，数据即不可逆。

逻辑删除：标记式隐藏

逻辑删除则通过添加如 is_deleted 字段标记记录状态，数据仍保留在表中，仅在查询时被过滤。例如：

UPDATE users SET is_deleted = 1, deleted_at = NOW() WHERE id = 100;

该语句将用户标记为已删除，而非真正移除。其优势在于可追溯、支持软恢复，适用于审计敏感系统。

• 物理删除：数据不可恢复，释放存储
• 逻辑删除：数据保留，状态变更
• 查询需配合 WHERE is_deleted = 0 过滤

特性	逻辑删除	物理删除
数据可见性	隐藏但存在	完全消失
恢复能力	可恢复	不可恢复

2.2 MyBatis-Plus中逻辑删除的实现机制

MyBatis-Plus通过字段标记实现逻辑删除，避免物理删除导致的数据丢失。核心是配置逻辑删除字段及值，框架自动拦截SQL并重写条件。

配置逻辑删除字段

在实体类中使用@TableLogic注解标记逻辑删除字段：

@TableField("is_deleted")
@TableLogic
private Integer deleted;

其中，deleted = 0表示未删除，deleted = 1表示已删除。

自动SQL重写机制

执行查询时，MyBatis-Plus自动追加过滤条件：

SELECT * FROM user WHERE is_deleted = 0;

删除操作则被改写为更新：

UPDATE user SET is_deleted = 1 WHERE id = ? AND is_deleted = 0;

该机制基于插件拦截器LogicDeleteInterceptor实现，在SQL解析阶段动态修改AST树，确保所有操作遵循逻辑删除规则。

2.3 全局配置与字段注解的协同工作原理

在现代 ORM 框架中，全局配置与字段注解通过元数据合并机制实现灵活的数据映射。全局配置定义默认行为，如命名策略、时区处理和连接池参数，而字段注解则提供细粒度控制。

优先级与覆盖机制

当两者同时存在时，字段注解优先于全局配置。例如，全局设置列名为下划线命名法，但可通过注解强制指定自定义列名。

@Entity
public class User {
    @Column(name = "user_email")
    private String email;
}

上述代码中，@Column 注解覆盖了全局的驼峰转下划线策略，明确指定数据库字段名。

元数据融合流程

框架启动时，会扫描所有实体类，结合全局配置构建元数据上下文。每个字段的最终映射规则由“默认值 + 注解修正”逐层计算得出，确保灵活性与一致性并存。

2.4 删除标记字段的设计规范与最佳实践

在软删除机制中，删除标记字段（如 `is_deleted` 或 `deleted_at`）是实现数据逻辑删除的核心。为确保系统一致性与可维护性，需遵循统一设计规范。

字段命名与类型

建议使用 `deleted_at` 而非布尔型 `is_deleted`，因其能记录删除时间且天然支持索引优化。若仅需状态标识，可采用 `is_deleted TINYINT DEFAULT 0`。

数据库层面约束

• 添加默认值约束：保证未删除记录显式标记
• 配合唯一索引时，需将删除标记纳入复合索引以避免重复冲突

ALTER TABLE users 
ADD COLUMN deleted_at TIMESTAMP NULL DEFAULT NULL,
ADD INDEX idx_deleted_at (deleted_at);

该语句添加了可空的时间戳字段，并建立索引，便于查询未删除数据（WHERE deleted_at IS NULL）。

应用层查询规范

所有读取操作应自动过滤已删除记录，可通过ORM作用域或视图封装，减少人为遗漏风险。

2.5 版本兼容性与常见误区解析

在跨版本升级过程中，开发者常忽视API变更带来的兼容性问题。例如，Go语言从1.x升级到2.x时，模块导入路径和错误处理机制发生显著变化。

常见兼容性陷阱

• 接口返回字段类型变更导致反序列化失败
• 废弃方法未被及时替换，引发运行时panic
• 依赖库版本冲突，造成行为不一致

代码示例：安全的版本适配

func OpenDatabase(version int) (*sql.DB, error) {
    if version < 2 {
        return legacyConnect() // 兼容旧版连接逻辑
    }
    return newConnect(context.Background()) // 使用上下文支持的新接口
}

该函数通过版本判断动态选择初始化路径，避免因接口变更导致服务中断，参数version用于标识目标数据库驱动版本。

推荐实践对照表

实践方式	风险等级
使用语义化版本约束	低
强制锁定主版本号	中

第三章：环境准备与项目集成实战

3.1 Spring Boot项目中引入MyBatis-Plus依赖

在Spring Boot项目中集成MyBatis-Plus，首先需要在pom.xml中添加对应依赖，以启用其增强功能。

添加Maven依赖

<dependency>
    <groupId>com.baomidou</groupId>
    <artifactId>mybatis-plus-boot-starter</artifactId>
    <version>3.5.3.1</version>
</dependency>

该依赖自动整合了MyBatis与Spring Boot，包含分页插件、条件构造器等核心模块，无需额外配置即可使用BaseMapper中的通用CRUD方法。

依赖版本选择建议

• 优先选择与Spring Boot主版本兼容的MyBatis-Plus版本
• 生产环境建议锁定稳定版本，避免SNAPSHOT版本带来的不稳定性
• 可通过官方文档查阅版本对应关系表

3.2 数据库表结构设计与删除标志字段定义

在软删除机制中，数据库表结构需包含逻辑删除标识字段，用于标记数据是否被“删除”。通常使用布尔类型或时间戳字段实现。

删除标志字段设计

常见的删除标志字段名为 deleted_at 或 is_deleted。推荐使用 deleted_at TIMESTAMP 类型，未删除时为 NULL，删除时记录时间戳。

ALTER TABLE users 
ADD COLUMN deleted_at TIMESTAMP DEFAULT NULL;

该字段支持高效查询未删除数据（WHERE deleted_at IS NULL），并保留删除时间信息，便于审计与恢复。

索引优化建议

为提升查询性能，应在删除标志字段上建立复合索引：

• 结合业务主键创建联合索引
• 避免全表扫描，提升软删除过滤效率

3.3 实体类映射与@TableLogic注解应用

在持久层框架中，实体类与数据库表的映射是数据操作的基础。通过注解方式可实现字段与表结构的精准对应。

逻辑删除的优雅实现

使用 @TableLogic 注解可实现逻辑删除功能，避免数据物理丢失。该注解通常作用于表示删除状态的字段：

@TableName("user")
public class User {
    private Long id;
    private String name;
    
    @TableLogic
    private Integer deleted;
}

上述代码中，deleted 字段标记为逻辑删除字段。默认情况下，未删除值为 0，删除后值为 1。查询时自动添加 WHERE deleted = 0 条件，保障数据安全性。

配置与行为控制

可通过全局配置修改逻辑删除的取值：

• 配置逻辑未删除值：logic-not-delete-value=0
• 配置逻辑已删除值：logic-delete-value=1

此机制提升系统数据可恢复性，同时保持业务逻辑简洁。

第四章：逻辑删除功能配置与高级用法

4.1 application.yml中全局逻辑删除配置项详解

在Spring Boot项目中，MyBatis-Plus支持通过`application.yml`配置全局逻辑删除行为，简化数据软删除操作。

配置项说明

mybatis-plus:
  global-config:
    db-config:
      logic-delete-field: deleted
      logic-delete-value: 1
      logic-not-delete-value: 0

上述配置定义了逻辑删除字段为`deleted`，值为`1`时表示已删除，`0`表示未删除。MyBatis-Plus在执行查询时自动添加`WHERE deleted = 0`条件，增删改操作也会自动处理字段值。

作用机制

• 查询操作自动过滤已删除记录
• 执行删除时更新标记而非物理删除
• 插入操作自动补全未删除默认值

该机制提升数据安全性，避免误删，同时保持查询透明性。

4.2 自定义逻辑删除值（0/1、true/false等）映射策略

在实际业务中，逻辑删除字段的取值可能为 0/1、true/false 或字符串类型。为适配不同数据源，需自定义映射策略。

支持多类型映射配置

通过枚举类或配置项定义删除状态的对应关系：

public enum DeleteStatus {
    NORMAL(0, "正常"),
    DELETED(1, "已删除");

    private final Integer code;
    private final String desc;

    DeleteStatus(Integer code, String desc) {
        this.code = code;
        this.desc = desc;
    }

    public static Boolean isDeleted(Object value) {
        return value != null && ((Integer.valueOf(1).equals(value)) || "true".equals(value));
    }
}

上述代码通过静态方法 isDeleted 统一判断删除状态，兼容数字与布尔字符串。

配置化映射规则

使用配置表管理不同系统的逻辑删除值映射：

系统名称	删除值	正常值
订单系统	1	0
用户中心	true	false

4.3 结合Wrapper查询避免已删除数据泄露

在软删除场景中，直接查询可能暴露已被逻辑删除的数据。为防止此类数据泄露，需通过查询Wrapper对条件进行封装。

使用QueryWrapper过滤已删除记录

QueryWrapper<User> wrapper = new QueryWrapper<>();
wrapper.eq("status", 1).ne("is_deleted", 1);
List<User> users = userMapper.selectList(wrapper);

上述代码通过eq确保用户状态有效，ne("is_deleted", 1)排除已标记删除的记录，从而在查询源头拦截敏感数据。

统一数据访问策略

• 所有查询操作应默认集成删除标识判断
• 建议封装基类Service，自动注入is_deleted = 0条件
• 结合MyBatis-Plus的自动填充功能，确保删除标记一致性

4.4 多租户或复杂场景下的扩展配置方案

在构建支持多租户架构的系统时，配置管理需兼顾隔离性与可扩展性。通过命名空间（Namespace）和标签（Label）机制实现租户间配置隔离是常见做法。

基于命名空间的配置隔离

• 每个租户对应独立的配置命名空间，避免配置冲突
• 动态加载租户专属配置，提升运行时灵活性

spring:
  cloud:
    nacos:
      config:
        namespace: ${TENANT_ID}
        group: TENANT_GROUP

上述配置通过 namespace 动态绑定租户ID，实现配置空间隔离。参数 TENANT_ID 在启动时注入，确保各租户加载各自上下文。

配置优先级控制

配置来源	优先级	适用场景
租户级配置	高	个性化定制
全局默认配置	低	基础共用设置

第五章：总结与生产环境建议

监控与告警策略

在生产环境中，服务的可观测性至关重要。建议集成 Prometheus 与 Grafana 实现指标采集与可视化，并配置关键阈值告警。例如，对 Go 服务的 GC 暂停时间进行监控：

// 在 Go 应用中暴露指标
import "github.com/prometheus/client_golang/prometheus/promhttp"

func main() {
    http.Handle("/metrics", promhttp.Handler())
    log.Fatal(http.ListenAndServe(":8080", nil))
}

资源限制与调度优化

Kubernetes 集群中应为每个 Pod 设置合理的资源 request 和 limit，避免资源争抢。以下为推荐配置示例：

服务类型	CPU Request	Memory Limit	建议副本数
API 网关	200m	512Mi	3
批处理任务	500m	2Gi	1（CronJob）

安全加固实践

生产环境必须启用最小权限原则。使用非 root 用户运行容器，并通过 RBAC 限制 Kubernetes ServiceAccount 权限：

• 禁用 Docker 的 privileged 模式
• 挂载只读文件系统根目录
• 启用 AppArmor 或 SELinux 策略
• 定期轮换 TLS 证书和密钥

灰度发布流程

采用 Istio 实现基于流量权重的渐进式发布。通过 VirtualService 控制请求分流，结合健康检查自动回滚异常版本。

用户请求 → 负载均衡器 → 90% v1 / 10% v2 → 监控响应延迟与错误率 → 自动扩容或回滚