如何在MyBatis Plus中配置MySQL逻辑删除避免真实物理数据丢失-mysql教程-PHP中文网

MyBatis-Plus逻辑删除需字段定义、@TableLogic注解和yml中logic-delete-field三者协同生效；缺一即导致物理删除，且自定义SQL、JdbcTemplate等绕过MP代理的操作不受保护。

如何在mybatis plus中配置mysql逻辑删除避免真实物理数据丢失

MyBatis-Plus 的逻辑删除不是“加个配置就自动生效”的黑盒，它依赖字段定义、注解声明和全局规则三者协同；只要漏掉任意一环，deleteById() 仍会执行物理删除（尤其在未配 logic-delete-field 或实体没加 @TableLogic 时）。

数据库表必须新增 deleted 字段并建索引

逻辑删除的前提是数据层有状态载体。不加字段，MP 根本无从改写 SQL。

字段类型优先用 TINYINT 或 INTEGER（MySQL），避免用 VARCHAR 或 BOOLEAN（后者在某些驱动下映射不稳定）
默认值必须设为 0：ALTER TABLE user ADD COLUMN deleted TINYINT DEFAULT 0 COMMENT '0-正常,1-已删除';
高并发读场景下务必加索引：CREATE INDEX idx_user_deleted ON user(deleted);，否则 SELECT 自动追加的 AND deleted = 0 会全表扫描
字段名可自定义（如 is_deleted、status），但后续所有配置必须严格对齐，不能大小写混用

@TableLogic 注解必须打在实体类字段上

MP 不靠字段名自动识别逻辑删除字段，@TableLogic 是触发机制的开关。没有它，即使 yml 配了全局规则，MP 也不会拦截该实体的 delete 操作。

最简写法：@TableLogic private Integer deleted;，此时使用默认值：未删=0，已删=1
若字段名不是 deleted（比如叫 is_deleted），必须显式指定：@TableLogic(value = "0", delval = "1") private Integer is_deleted;
如果用了 Lombok 的 @Data，确保字段名与数据库列名一致；否则需配合 @TableField("is_deleted") 显式映射
多个逻辑删除字段？MP 不支持——一个实体只允许一个 @TableLogic 字段

application.yml 中 logic-delete-field 必须显式声明

很多人以为只配 logic-delete-value 和 logic-not-delete-value 就够了，其实 logic-delete-field 是必填项。不填，MP 默认尝试匹配字段名 deleted，一旦实体字段叫 is_deleted 就失效。

win可用的mysql指令skill

安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。

下载

正确配置示例：

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

注意缩进层级：db-config 下，不是 configuration 或 mapper-locations 下
如果实体类已用 @TableLogic(value = "0", delval = "1") 显式标注，则 yml 中对应字段的配置会被忽略（注解优先级更高）
多模块项目中，确保该配置落在启动模块的 application.yml，而非被 @Profile 隔离的 profile 文件里

自定义 XML SQL 不受逻辑删除影响

这是最容易踩坑的地方：MP 的逻辑删除仅作用于 MP 自动生成的 SQL（如 selectList()、deleteById()），所有手写的、标签都不会自动追加 AND deleted = 0 条件。

手动 SQL 查询时，必须显式加条件：WHERE is_deleted = 0 AND ...
手动 SQL 删除时，严禁写 DELETE FROM user WHERE id = #{id}，应改为 UPDATE user SET is_deleted = 1 WHERE id = #{id} AND is_deleted = 0
连表查询（如 user JOIN order）中，若 order 表也启用了逻辑删除，两个表的 deleted 条件都得手写，MP 不会帮你推导
动态 SQL（）里也别依赖 MP 自动注入——它压根不进那条执行路径

真正要防住物理删除，关键不在“配了多少”，而在“是否每处 delete 操作都经过 MP 的代理入口”。绕过 BaseMapper 直接调 JdbcTemplate 或原生 Statement，逻辑删除就彻底失效。上线前建议 grep 全局代码里的 DELETE FROM 和 drop table，确认它们只存在于测试或初始化脚本中。