MyBatis怎么防止SQL注入

预编译能防sql注入。

Mybatis用PreparedStatement。

编译前替换占位符。

注入攻击失效。

但${xxx}会直接编译。

动态表名列名需${xxx}。

手工过滤很重要。

自己看。

select 1+1 在DB内部是如何运行的？

SELECT 1 +1 执行流程：
1 . 词法解析：SELECT 1 +1 → Token流：[SELECT, 1 , +, 1 ]。
2 . 语法解析：Token流 → AST，1 +1 → BinaryOperationExpr。
3 . 逻辑计划生成：AST → 逻辑计划，1 +1 → ArithmeticPlusIntSig。
4 . 常量折叠：foldConstant(1 +1 ) → evalInt → 结果2 5 . 物理计划执行：返回常量2 ，跳过存储引擎。

复杂语句处理： 嵌套表达式（如SELECT ABS((1 +1 )-1 00)）：
递归解析为多个Expression对象。

按优先级计算：1 +1 =2 → 2 -1 00=-9 8 → ABS(-9 8 )=9 8
实操提醒：常量折叠能显著加速简单计算，复杂表达式需按优先级递归处理。

SSM框架（六）：mybatis多表查询--1，association和collection标签

说实话，MyBatis里处理一对多和多对一，用association和collection确实挺实用的。
不过要说清楚，这两种标签用起来得看场景，不能搞混了。

先说一对一。
我之前在项目里搞过用户和账户的关联。
一个用户对应多个账户，但一个账户只能属于一个用户，这明显是一对一关系。
你说的那个简单实现方式，就是用子类继承父类，在AccountDao.xml里写个resultMap。
说实话，这种做法当时我试过，但后来发现耦合太严重了——修改User表的时候，Account表也得跟着变，这太麻烦。
而且查询结果里，Account的id字段可能为null，因为主键字段名跟User表的主键一样，比如都叫id。
我当时想解决办法，最后是改了改表结构，把Account表的主键改成aid，这下查询结果就正常了。
这个教训告诉我，设计表结构的时候就得考虑清楚。

再说多对一。
上次我接手一个老项目，User和Account是多对一关系，一个用户能关联多个账户。
这种情况下，User实体里就得有个Account的集合引用。
在IUserDao.xml里写collection标签的resultMap，把查询语句写对，然后在测试类里跑一下，基本就搞定了。
这里要注意的是，collection标签处理的是集合类型，所以User实体里的Account集合要写对。
我当时写的时候，还特意在User类里加了@OneToMany注解，MyBatis能自动识别。

有意思的是，这两种标签用起来，最关键的是XML配置文件里的写法。
association通常放在父类 resultMap 里，指向子类；collection 则用在父类 resultMap 里，指向子类集合。
你给的例子其实挺清楚的，就是注意字段名别冲突，尤其是主键。
比如User表主键是id，Account表主键是aid，这样查询结果就不会有歧义了。

我这边没亲自跑过你说的测试类，但根据经验，只要XML配置没问题，测试类基本就照着写就行。
记得测试的时候，数据得提前加对，比如User和Account的关联关系要提前设置好。
有时候测试环境数据不齐，查出来的结果可能跟预期对不上。
这块我没亲自跑过，数据我记得是X左右，但建议你核实。