超详细MyBatis中 #{} 和 ${} 区别

Mybatis的Mapper映射文件中,有两种方式可以引用形参变量进行取值: #{} 和 ${}。本文将简述两种方式的区别和适用场景。

一、取值引用

1) #{} 方式

#{}: 解析为SQL时,会将形参变量的值取出,并自动给其添加引号。 例如:当实参username="Amy"时,传入下Mapper映射文件后

    <select id="findByName" parameterType="String" resultMap="studentResultMap">
        SELECT * FROM user WHERE username=#{value}
    </select>

SQL将解析为:

SELECT * FROM user WHERE username="Amy"

2) ${} 方式

${}: 解析为SQL时,将形参变量的值直接取出,直接拼接显示在SQL中

例如:当实参username="Amy"时,传入下Mapper映射文件后

<select id="findByName" parameterType="String" resultMap="studentResultMap">
        SELECT * FROM user WHERE username=${value}
</select>

SQL将解析如下:

SELECT * FROM user WHERE username=Amy
显而该SQL无法正常执行,故需要在mppaer映射文件中的${value}前后手动添加引号,如下所示:

<select id="findByName" parameterType="String" resultMap="studentResultMap">
        SELECT * FROM user WHERE username='${value}'
</select>

SQL将解析为:

SELECT * FROM user WHERE username='Amy'

二、SQL 注入

${}方式是将形参和SQL语句直接拼接形成完整的SQL命令后,再进行编译,所以可以通过精心设计的形参变量的值,来改变原SQL语句的使用意图从而产生安全隐患,即为SQL注入攻击。现举例说明:

现有Mapper映射文件如下:

<select id="findByName" parameterType="String" resultMap="studentResultMap">
        SELECT * FROM user WHERE username='${value}'
</select>

当 username = “’ OR 1=1 OR '” 传入后,${}将变量内容直接和SQL语句进行拼接,结果如下:

SELECT * FROM user WHERE username='' OR 1=1 OR '';

显而易见,上述语句将把整个数据库内容直接暴露出来了

#{}方式则是先用占位符代替参数将SQL语句先进行预编译,然后再将参数中的内容替换进来。由于SQL语句已经被预编译过,其SQL意图将无法通过非法的参数内容实现更改,其参数中的内容,无法变为SQL命令的一部分。故,#{}可以防止SQL注入而${}却不行

三、适用场景

1)#{} 和 ${} 均适用场景

由于SQL注入的原因,${}和#{}在都可以使用的场景下,很明显推荐使用#{}。这里除了上文的WHERE语句例子,再介绍一个LIKE模糊查询的场景(username = “Amy”):

<select id="findAddByName" parameterType="String" resultMap="studentResultMap">
        SELECT * FROM user WHERE username LIKE '%${value}%'
</select>

该SQL解析为:

SELECT * FROM user WHERE username LIKE '%Amy%';

上述通过${}虽然可以实现对包含"Amy"对模糊查询,但是不安全,可以改用#{},如下所示:

<select id="findAddByName" parameterType="String" resultMap="studentResultMap">
        SELECT * FROM USER WHERE username LIKE CONCAT('%', #{username}, '%')
</select>

该SQL解析为下文所示,其效果和上文方式一致

SELECT * FROM USER WHERE username LIKE CONCAT('%', 'Amy','%');

2)只能使用${}的场景

由于#{}会给参数内容自动加上引号,会在有些需要表示字段名、表名的场景下,SQL将无法正常执行。现举一例说明:

期望查询结果按sex字段升序排列,参数String orderCol = “sex”,mapper映射文件使用#{}:

<select id="findAddByName3" parameterType="String" resultMap="studentResultMap">
        SELECT * FROM USER WHERE username LIKE '%Am%' ORDER BY #{value} ASC
</select>

则SQL解析及执行结果如下所示,很明显 ORDER 子句的字段名错误的被加上了引号,致使查询结果没有按期排序输出

SELECT * FROM USER WHERE username LIKE '%Am%' ORDER BY 'sex' ASC;

这时,现改为${}测试效果:

<select id="findAddByName3" parameterType="String" resultMap="studentResultMap">
        SELECT * FROM USER WHERE username LIKE '%Am%' ORDER BY ${value} ASC
</select>

则SQL解析及执行结果如下所示:

SELECT * FROM USER WHERE username LIKE '%Am%' ORDER BY sex ASC;
<think>好的,我现在要帮助用户理解MyBatis中的逻辑分页物理分页的区别及实现方式,以及它们的性能比较。首先,我需要回忆一下自己之前学过的相关知识,并结合用户提供的引用内容来组织回答。 首先,用户的问题是关于MyBatis的逻辑分页物理分页的区别、实现机制性能比较。我需要明确这两个概念的定义,以及它们各自的实现方式。根据用户提供的引用内容,逻辑分页是MyBatis通过RowBounds或类似机制在内存中处理分页,而物理分页是在数据库层面进行分页,比如使用LIMITOFFSET或者分页插件如PageHelper。 接下来,我需要分别详细说明两者的实现机制。逻辑分页方面,用户提到的引用34指出,逻辑分页使用RowBounds,执行完整的SQL查询后,在内存中截取需要的数据。这可能适用于数据量小的情况,但数据量大时会有内存问题。物理分页则是通过修改SQL语句,添加分页参数,比如MySQL的LIMIT,这样数据库只返回特定范围的数据,减少了内存占用。 然后,性能比较部分需要结合引用23中的优缺点。逻辑分页在数据量小时效率高,因为不需要多次查询数据库,但数据量大时内存消耗大,甚至导致溢出。物理分页虽然每次都要访问数据库,但处理大数据量时更稳定,内存占用低,不过可能需要更复杂的SQL语句或插件支持。 我还需要提到具体的实现方式,比如逻辑分页的RowBounds用法,以及物理分页的PageHelper插件示例。引用4中提到了PageHelper的使用方法,可以结合代码示例来说明物理分页的实现。同时,引用3中比较了两者的优缺点,这有助于在性能比较部分展开讨论。 可能还需要考虑适用场景,比如什么时候选择逻辑分页,什么时候选择物理分页。根据引用2,逻辑分页适用于数据量小的情况,而物理分页适合大数据量,避免内存问题。此外,用户可能需要知道如何在实际项目中配置使用这两种分页方式,所以给出示例代码会更有帮助。 最后,生成相关问题时要围绕主题,可能涉及实现细节、优化方法、选择依据等。需要确保问题能够引导用户进一步探索相关内容,同时覆盖用户可能关心的其他方面。 现在需要整理这些思路,确保回答结构清晰,分点明确,引用正确的文献,并且语言自然流畅,符合用户的要求。同时要检查LaTeX格式是否正确,虽然这个问题可能不涉及数学公式,但如果有变量或代码块需要正确标注。不过根据问题内容,可能主要是代码块引用标注需要注意格式。</think>### MyBatis逻辑分页与物理分页对比分析 #### 一、实现机制 1. **逻辑分页** - **定义**:通过`RowBounds`或类似机制,在代码层面对查询结果进行内存分页。 - **实现方式**: - 执行完整的SQL查询,将**所有数据加载到内存**,再根据分页参数截取部分数据。 - 示例代码: ```java List<User> users = sqlSession.selectList("selectUsers", params, new RowBounds(offset, limit)); ``` - 引用说明:逻辑分页依赖内存截取数据,可能导致内存溢出风险[^2][^3]。 2. **物理分页** - **定义**:通过修改SQL语句,直接在数据库层面完成分页。 - **实现方式**: - 使用数据库方言(如MySQL的`LIMIT offset, limit`)或分页插件(如`PageHelper`)。 - 示例代码(PageHelper): ```java PageHelper.startPage(pageNum, pageSize); List<User> users = userDao.selectUserList(); PageInfo<User> pageInfo = new PageInfo<>(users); ``` - 引用说明:物理分页通过SQL优化减少数据传输量[^4]。 --- #### 二、性能对比 | 维度 | 逻辑分页 | 物理分页 | |--------------|--------------------------------------------------------------------------|--------------------------------------------------------------------------| | **内存占用** | 高(需加载全量数据)[^2] | 低(仅返回分页数据)[^3] | | **数据库压力** | 大(单次全量查询) | 小(分页条件限制查询范围) | | **响应速度** | 数据量小时快;数据量大时可能因内存不足崩溃 | 数据量大时稳定,但复杂查询可能因分页次数多而略慢 | | **数据实时性** | 数据为查询时的快照,后续变化不更新[^3] | 每次查询直接从数据库获取最新数据 | --- #### 三、适用场景 1. **逻辑分页** - 数据量小(如千级以下) - 需要频繁遍历全量数据的场景 - 引用警告:数据量超万级时需谨慎使用。 2. **物理分页** - 大数据量(万级以上) - 高并发场景(如Web应用分页展示) - 引用建议:优先选择物理分页以避免内存问题[^4]。 --- #### 四、优化建议 1. **物理分页的SQL优化** - 避免使用`offset`过大(可改用`WHERE id > last_id LIMIT n`)。 - 添加索引优化查询条件。 2. **逻辑分页的替代方案** - 结合缓存机制(如Redis)减少数据库压力。 ---
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值