【ORM 框架】#{} vs ${} 区别、SQL 注入防范、动态 SQL、懒加载原理

简介: 本文系统解析MyBatis中`#{}`与`${}`的本质差异、SQL注入防护原理、动态SQL执行机制及懒加载实现逻辑,涵盖预编译安全边界、OGNL动态拼接、CGLIB代理延迟加载等核心机制,助力开发者深入理解ORM底层设计。

思维导图

ORM框架核心知识体系:#{}与${}、SQL注入、动态SQL、懒加载

本文以业界最典型的MyBatis(半自动化ORM)为核心载体,系统化梳理参数占位符、注入防护、动态SQL、懒加载四大模块的底层原理与实践边界,形成完整的知识闭环。


一、ORM框架的核心定位

ORM(Object-Relational Mapping,对象关系映射)的核心目标是解决面向对象编程语言与关系型数据库的数据模型不匹配问题,通过封装JDBC操作,实现Java对象与数据库表的映射,让开发者以操作对象的方式操作数据库,同时兼顾SQL灵活性。

其中:

  • #{} / ${} 是ORM参数绑定的两种核心机制,决定SQL的编译方式与安全边界;
  • 动态SQL 是ORM实现SQL灵活拼接的核心能力,解决多条件查询、动态表/列名等场景;
  • 懒加载 是ORM的性能优化机制,解决关联查询的N+1问题与不必要的数据加载。

二、#{} 与 ${} 的本质区别(参数处理机制)

1. 底层执行机制

(1)#{}:预编译参数化处理

  • 本质:JDBC PreparedStatement 的参数占位符,属于预编译机制
  • 执行流程
    1. MyBatis解析SQL时,将 #{xxx} 统一替换为 ? 占位符;
    2. 数据库驱动对SQL进行预编译,SQL的语义、执行计划在此时已固定;
    3. 执行阶段通过 PreparedStatement.setXxx() 方法传入参数,参数仅作为纯数据处理,驱动会自动完成类型转换与特殊字符转义。
  • 关键特性:参数不会改变SQL的语法结构,仅作为值参与执行。

(2)${}:静态字符串拼接

  • 本质:SQL语句的字符串替换,属于编译前的文本拼接。
  • 执行流程
    1. 在SQL解析阶段,直接将 ${xxx} 替换为变量的实际取值,生成完整的SQL字符串;
    2. 替换完成后,再将完整SQL交给JDBC StatementPreparedStatement 执行;
    3. 整个过程参数与SQL文本直接融合,参数内容会直接影响SQL结构。
  • 关键特性:参数是SQL文本的一部分,可改变SQL语义与执行逻辑。

2. 多维度核心对比

对比维度 #{} 预编译占位符 ${} 字符串替换
处理时机 SQL预编译阶段(编译后参数传入) SQL解析阶段(编译前文本替换)
底层对象 基于 PreparedStatement 基于字符串拼接,最终可由 Statement 执行
SQL注入风险 无(参数化查询天然防注入) 极高(直接拼接,恶意参数可篡改SQL)
类型处理 自动匹配Java类型与JDBC类型,自动转义特殊字符 纯文本替换,需手动处理类型与引号
适用场景 普通参数(查询条件、插入/更新值) 动态表名、动态列名、排序字段、SQL关键字
性能表现 支持SQL执行计划缓存,重复执行性能更高 每次生成不同SQL,无法复用执行计划
语法细节 字符串参数无需手动加单引号 字符串参数必须手动加单引号 '${name}'

3. 选型原则

  • 绝大多数业务参数优先使用 #{},这是安全与性能的默认选择;
  • 仅当需要动态修改SQL结构本身时(表名、列名、排序方向、表分区等),才使用 ${},且必须配合安全校验。

三、SQL注入防范原理

1. SQL注入攻击的本质

攻击者通过在输入参数中嵌入恶意SQL片段,篡改原有SQL的语义结构,从而执行非授权操作(如拖库、删表、越权查询等)。

典型攻击示例:传入参数 name = ' OR '1'='1,拼接后SQL变为:

SELECT * FROM user WHERE name = '' OR '1'='1'

条件恒成立,直接泄露全表数据。

2. #{} 防注入的底层原理

{} 防注入的核心是SQL语义与数据分离,依赖JDBC预编译机制实现:

  1. 语义固化:SQL预编译阶段,执行计划就已生成,? 占位符的位置只能传入数据,不能改变SQL的语法结构;
  2. 自动转义:数据库驱动会对参数中的特殊字符(单引号、分号、注释符等)进行转义处理,确保参数仅作为字符串/数值生效,不会被解析为SQL指令;
  3. 参数隔离:参数通过二进制协议单独传输,而非拼接在SQL文本中,从传输层避免注入。

3. ${} 的注入风险与安全方案

${} 直接拼接SQL文本,完全不具备防注入能力,必须通过业务层手段兜底:

  • 白名单校验:对动态表名、列名、排序字段做枚举校验,只允许预设的合法值传入;
  • 正则过滤:拦截参数中的SQL关键字(';--dropunion等),但存在绕过风险,仅作辅助;
  • 参数映射:前端传索引/编码,后端映射为真实表/列名,避免直接暴露数据库元数据。

4. 易踩坑的边界场景

  • 模糊查询:禁止写 LIKE '%${name}%',正确写法为 LIKE CONCAT('%', #{name}, '%')
  • IN 条件:禁止拼接 ${ids},使用 <foreach> 标签 + #{item} 实现;
  • 动态排序ORDER BY ${sortField} 必须加白名单,不能直接接收前端参数。

四、动态SQL的实现与原理

动态SQL指根据不同的业务条件,动态拼接生成不同的SQL语句,解决多条件组合查询、批量操作等场景下SQL硬编码问题。

1. MyBatis动态SQL核心标签体系

标签 作用 典型场景
<if> 条件判断,满足则拼接SQL片段 多条件查询(姓名、年龄、状态可选)
<choose>/<when>/<otherwise> 分支选择,类似switch-case 多条件互斥场景
<where> 智能拼接WHERE关键字,自动去除多余的AND/OR 多条件查询的WHERE子句
<set> 智能拼接SET关键字,自动去除多余逗号 动态更新字段
<trim> 自定义前缀/后缀,可替代where/set 复杂SQL片段的前后缀处理
<foreach> 遍历集合,生成IN、批量插入等SQL IN查询、批量插入/更新
<sql>/<include> SQL片段抽取与复用 公共字段、公共条件复用

2. 底层执行原理

MyBatis动态SQL的核心是基于OGNL表达式的SQL解析引擎,完整流程如下:

  1. 配置解析阶段XMLStatementBuilder 解析Mapper.xml中的SQL节点,识别动态标签;
  2. 动态节点处理:将SQL拆分为多个 SqlNode 节点(静态文本、if节点、foreach节点等),形成节点树;
  3. 条件求值:执行SQL时,传入参数对象,通过OGNL表达式引擎计算每个动态标签的条件是否成立;
  4. SQL拼接:遍历SqlNode树,将满足条件的节点拼接成完整的SQL字符串;
  5. 参数替换:拼接完成后,再对SQL中的 #{} 替换为 ?${} 做文本替换,最终生成可执行SQL。

3. 动态SQL与参数占位符的协作

  • 动态标签(if/foreach等)负责SQL结构的动态生成,决定哪段SQL生效;
  • #{} / ${} 负责参数值的绑定,决定数据如何传入;
  • 最佳实践:动态结构用标签实现,参数值用 #{} 传入,仅在标签无法解决的结构动态场景下使用 ${}

五、懒加载(延迟加载)原理

1. 核心概念与适用场景

懒加载(Lazy Loading)也叫延迟加载,指在查询主对象时,不立即加载关联的对象数据,仅在真正使用关联对象时才触发SQL查询

  • 核心价值:避免不必要的关联查询,解决关联查询的N+1问题,提升查询性能;
  • 典型场景:一对多、多对多关联(如查询用户时不立即查询其所有订单,调用user.getOrders()时才查询)。

2. 底层实现机制:动态代理

MyBatis懒加载的核心技术是字节码动态代理,默认使用CGLIB代理(也可配置JDK动态代理),原理如下:

  1. 结果映射阶段:查询主对象后,处理关联属性(association/collection)时,不直接实例化关联对象;
  2. 代理对象创建:通过 ProxyFactory 为关联属性创建代理对象,代理对象内部持有主对象的上下文与待执行的关联查询SQL;
  3. 方法拦截:当代码调用关联对象的getter方法(如 user.getOrders())时,代理对象的 MethodInterceptor 拦截方法调用;
  4. 触发加载:拦截后调用 ResultLoader 执行预设的关联SQL,查询真实数据并赋值给代理对象,后续调用直接返回已加载的数据。

3. MyBatis核心配置与触发逻辑

配置项 默认值 作用
lazyLoadingEnabled false 全局开启/关闭懒加载
aggressiveLazyLoading false 开启后,调用主对象的equals、hashCode、toString等方法会触发全量懒加载;关闭后仅调用getter时触发
lazyLoadTriggerMethods equals,clone,hashCode,toString 指定触发懒加载的方法列表
fetchType - 局部指定单个关联的加载策略(lazy/eager),优先级高于全局配置

4. 优缺点与适用边界

  • 优点:减少不必要的数据库查询,降低内存开销,提升主查询速度;
  • 缺点:多次查询会增加数据库交互次数(N+1问题),不适合批量数据处理;
  • 适用场景:关联数据使用概率低、主查询性能要求高、单条数据查询为主的场景;
  • 不适用场景:批量数据导出、列表页关联数据必展示的场景(建议用联表查询替代)。

六、知识体系串联与实践原则

  1. 安全底线:参数绑定默认用 #{}${} 仅用于SQL结构动态化,且必须加白名单校验;
  2. 灵活与规范平衡:动态SQL解决结构变化,避免硬编码,但禁止过度动态导致SQL不可维护;
  3. 性能取舍:懒加载是“时间换空间”的优化策略,需结合业务数据访问模式选型,避免N+1性能反噬;
  4. 底层本质:四大能力最终都围绕ORM的核心矛盾——对象模型与关系模型的映射效率、开发效率与运行效率的平衡
相关文章
SQL 缓存 Java
29 4
SQL Java 数据库连接
21 0
消息中间件 存储 弹性计算
23 0
人工智能 监控 开发者
39 0
SQL Java 数据库连接
27 1
Windows
455 1
|
5月前
|
安全 Java 数据库连接
【反射】Java反射 全方位知识体系(附 应用场景 + 《八股文常考面试题》)
Java反射是运行时动态获取类元信息(构造器、方法、字段等)并操作对象的能力,核心为 Class对象。广泛应用于Spring、MyBatis等框架的IoC、AOP、ORM映射,以及注解处理、动态代理、SPI扩展等场景,兼具灵活性与解耦优势,但存在性能开销和安全风险。
624 10
|
5月前
|
存储 缓存 安全
【HashMap】HashMap 系统性知识体系全解(附《HashMap 面试八股文精简版》)
本文以JDK8为核心,对比JDK7差异,从基础认知、底层结构(数组+链表+红黑树)、哈希函数、扩容机制、线程安全、最佳实践及面试考点七大维度,系统解析HashMap原理与应用,助你构建完整知识体系。
Ubuntu Linux iOS开发
242 0
人工智能
132 0

热门文章

最新文章