解决 MyBatis-Plus 逻辑删除踩坑delete 关键字导致 SQL 语法错误一. 问题背景1. 核心代码片段1.1 业务代码统计当日数据1.2 实体类逻辑删除配置1.3 报错信息二、问题根因分析1.核心原因delete 是 MySQL 关键字2.MyBatis-Plus 逻辑删除的自动拼接逻辑三. 解决方案方案1. 实体类调整方案2. 数据库字段命名规范结论一. 问题背景日常开发中使用 MyBatis-Plus 的逻辑删除功能时遇到了一个典型的语法错误问题。场景是统计当日新增数据量代码逻辑看似正常但执行后抛出 SQL 语法错误核心报错指向delete0附近的语法问题。1. 核心代码片段1.1 业务代码统计当日数据LocalDate today LocalDate.now(); String startTime today 00:00:00; String endTime today 23:59:59; // 构造查询条件 LambdaQueryWrapperTSetMain queryWrapper new LambdaQueryWrapper(); queryWrapper.ge(TSetMain::getGmtCreate, startTime) .le(TSetMain::getGmtCreate, endTime); // 统计当日数据量 Integer todayCount tSetMainMapper.selectCount(queryWrapper);1.2 实体类逻辑删除配置DataTableName(t_set_main)publicclassTSetMain{// 其他字段省略.../** * 逻辑删除标识0-未删除 1-已删除 */TableLogic(value0,delval1)// MyBatis-Plus逻辑删除注解privateIntegerdelete;/** * 创建时间 */privateLocalDateTimegmtCreate;}1.3 报错信息SQL: SELECT COUNT( 1 ) FROM t_set_main WHERE delete0 AND (gmt_create ? AND gmt_create ?)Cause: java.sql.SQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near delete0 AND (gmt_create ‘2026-03-09 00:00:00’ AND gmt_create ‘2026-03-09’ at line 2二、问题根因分析1.核心原因delete 是 MySQL 关键字delete是 MySQL 的保留关键字用于 DELETE 删除语句直接在 SQL 中写delete0会被 MySQL 识别为语法错误因为数据库无法区分这是字段名还是关键字。2.MyBatis-Plus 逻辑删除的自动拼接逻辑MyBatis-Plus 的TableLogic注解会自动给所有查询语句拼接DELETE0未删除的条件无需手动添加。但由于字段名delete是关键字拼接后的 SQL 缺少字段名转义导致语法错误。三. 解决方案方案1. 实体类调整TableLogic(value0,delval1)TableField(delete)privateIntegerdelete;显式指定带反引号的字段名MySQL 能识别为字段TableField 注解的核心作用注解写法生成的 SQL 片段是否报错原因无 TableFielddelete0报错MyBatis-Plus 默认用属性名delete作为字段名无转义TableField(“delete”)delete0报错显式指定字段名为delete仍无反引号转义TableField(“delete”)delete0正常显式指定带反引号的字段名MySQL 能识别为字段方案2. 数据库字段命名规范优先用 is_deleted/del_flag 替代 delete 作为逻辑删除字段名从根源避免关键字冲突结论1.反引号是关键字字段的 “救命符”若数据库字段名必须使用 MySQL 保留关键字如 delete、update必须在TableField中用反引号包裹字段名TableField(“delete”)2.TableField 的优先级高于默认规则MyBatis-Plus 会优先使用TableField指定的字段名包括反引号拼接 SQL而非实体属性名3. 数据库字段命名规范从根源避免关键字冲突。