SQL报错：java.sql.SQLException: sql injection violation, dbType mysql

原创已于 2025-11-21 17:01:45 修改 · 5.5w 阅读

8 ·

CC 4.0 BY-SA版权

文章标签：

#sql #java #mysql #idea

于 2021-11-16 09:51:08 首次发布

报错问题专栏收录该内容

90 篇文章

订阅专栏

报错信息如下：

java.sql.SQLException: sql injection violation, dbType mysql

注意sql injection violation，字面理解就是sql注入错误，多数情况都是列名被怀疑是sql注入，所以被DB拒绝，需要检查字段（比如用户id在别的地方是user_Id，但在user自己表里面即主键就叫id）

一般情况下，都是因为表字段和关键字冲突，触发了防 SQL 注入的安全规则，常见于 JDBC、MyBatis-Plus，这些组件会拦截疑似包含有注入风险的 SQL，比如拼接字符串、明显不对经的函数、没有参数化的条件等。这个问题在解决后多数情况下SQL都正常了。如果开发工具不显示SQL关键字不方便区分的话，暂时我只知道三种解决办法：

一、可以把感觉不对劲的表名和字段名都用 ` ` 给注上，如`state`

二、给冲突的字段或表名起别名

三、还可以在oracle中使用双引号""，将冲突的列名括起来

比如：select * from user where "name" = "张三他叔"

下面是我总结的会触发这个报错的场景：

场景 1：直接拼接 SQL 字符串（最常见）

错误示例：

// 危险：直接拼接用户输入，极易触发注入拦截
String userId = request.getParameter("userId");
String sql = "SELECT * FROM user WHERE id = " + userId; 
PreparedStatement pstmt = conn.prepareStatement(sql);

解决方案：使用参数化查询（PreparedStatement）

String userId = request.getParameter("userId");
String sql = "SELECT * FROM user WHERE id = ?"; // 占位符
PreparedStatement pstmt = conn.prepareStatement(sql);
pstmt.setString(1, userId); // 参数化赋值
ResultSet rs = pstmt.executeQuery();

场景 2：MyBatis 中使用 ${} 拼接参数（而非 #{}）

${} 是字符串替换（直接拼接），#{} 是参数化（预编译），前者极易触发注入拦截。

错误示例（MyBatis Mapper）：

<!-- 危险：${}直接拼接，触发注入拦截 -->
<select id="getUser" resultType="User">
    SELECT * FROM user WHERE id = ${userId}
</select>

解决方案：替换为 #{} 参数化

<select id="getUser" resultType="User">
    SELECT * FROM user WHERE id = #{userId}
</select>

特殊场景（必须用 ${}，比如表名 / 字段名动态拼接）：如果需要动态表名 / 字段名（如分表），需做白名单校验 + 关闭针对性拦截：

// 1. 白名单校验（仅允许合法表名）
Set<String> allowedTables = Set.of("user_2024", "user_2025");
String tableName = request.getParameter("tableName");
if (!allowedTables.contains(tableName)) {
    throw new IllegalArgumentException("非法表名");
}
// 2. MyBatis中使用${}（已做白名单，安全）
String sql = "SELECT * FROM ${tableName} WHERE id = #{userId}";

场景 3：Druid 连接池开启了 SQL 注入检测（wall-filter）

Druid 的 WallFilter 会严格校验 SQL 语法，拦截疑似注入的语句（比如包含 OR 1=1、UNION、EXEC 等关键词）。

解决方案：

优先修复 SQL（参数化），而非直接关闭拦截；
若确需放行（如合法的批量操作），可精细化配置 WallFilter：

# druid配置文件
druid.wall.mysql.enable=true
# 放行特定关键词（按需配置，避免过度放开）
druid.wall.config.delete-allow=false
druid.wall.config.drop-table-allow=false
# 白名单SQL（精准放行）
druid.wall.config.select-all-column-allow=true
druid.wall.config.condition-and-always-true-allow=false

场景 4：Sharding-JDBC 分库分表的 SQL 校验

Sharding-JDBC 对分表 SQL 的语法校验严格，比如：

分表字段未在 WHERE 条件中；
使用了不支持的函数（如 NOW() 拼接参数）；
动态拼接 ORDER BY/GROUP BY 字段。

解决方案：

确保分表字段出现在 WHERE 条件中；
对动态字段做白名单校验；
关闭不必要的 SQL 校验（谨慎）：

# sharding-jdbc配置
spring:
  shardingsphere:
    rules:
      sql-translator:
        type: NONE # 关闭SQL翻译校验
      sql-parser:
        sql-comment-parse-enabled: false # 关闭注释解析

场景 5：SQL 中包含危险关键词 / 语法

比如 SQL 中包含：

OR 1=1、UNION SELECT、INSERT INTO ... VALUES (${恶意参数})；
多条 SQL 拼接（如 SELECT * FROM user; DROP TABLE user;）；
使用 EXEC、xp_cmdshell 等危险函数。

解决方案：

过滤用户输入中的危险关键词（如 OR、UNION、DROP）；
禁止多条 SQL 拼接执行（关闭 JDBC 的 allowMultiQueries=true）；
最小化数据库账号权限（如不授予 DROP、ALTER 权限）。

通用排查步骤

定位触发的 SQL：在日志中找到报错前执行的 SQL 语句；
检查参数传递方式：是否用了字符串拼接 /${} 而非参数化 /#{}；
验证防注入组件配置：Druid WallFilter、Sharding-JDBC、MyBatis 插件的规则；
模拟测试：用合法参数执行 SQL，确认是否仅恶意参数触发报错；
临时关闭校验（测试环境）：关闭防注入校验后，若 SQL 能执行，说明是规则拦截，需优化 SQL 而非关闭校验。

注意：始终使用参数化查询（PreparedStatement/#{}），从根源避免注入；❌ 禁止：直接拼接用户输入到 SQL 中，哪怕做了简单的字符替换；⚠️ 注意：白名单校验仅用于必须动态拼接表名 / 字段名的场景，且需严格限制范围。

如果能提供具体的 SQL 语句和相关配置（如 Druid/Sharding-JDBC 配置），可以给出更精准的修复方案。

所以为了避免这种情况，在数据库最初建表时需要有意识的避免字段冲突问题

下面是网上找的建表命名规范：
l 采用“系统名+_+t_+模块名+_+表义名”格式构成。
l 若数据库中只含有单个模块，命名可采用“系统名+t_+表义名”格式构成。
l 整个表名的长度不要超过30个字符。
l 系统名、模块名均采用小写字符。
l 模块名或表义名均以其英文单词命名，且字符间不加分割符；表义名中单词的首字符大写，其它字符小写，多个单词间也不加任何分割符，单词全部采用单数形式。
l 表别名命名规则：取表义名的前3个字符加最后一个字符。如果存在冲突，适当增加字符（如取表义名的前4个字符加最后一个字符等）。
l 关联表命名为Re_表A_表B,Re 是Relative的缩写，表A 和表B均采用其表义名或缩写形式。
这样会避免与关键字冲突，将麻烦降到最低。