这里所说的SQL解析只是针对在iBatis配置文件中所定义的SQL语句。和标准的SQL语句不同的是，参数的赋值是“#”包裹的变量名。如何解析这个变量就是iBatis要完成的工作。当然SQL的表达形式还有很多其他形式，如动态SQL等。

当我们执行如下查询方法时:

accountDAO.selectAccountById(account)

iBatis将会选择前面那个Statement来解析，最终会把他解析成一个标准的SQL提交给数据库执行，并且会设置两个选择条件参数。在这个过程中参数映射的细节是什么样子的呢？

iBatis会把SqlMap配置文件解析成一个个Statement，其中包括ParameterMap、ResultMap，以及解析后的SQL。当iBatis构建好RequestScope执行环境后，其要做的工作就是把传过来的对象数据结合ParameterMap中的信息提取出一个参数数组，这个数组的顺序对应于SQL中参数的顺序，然后会调用preparedStatement.setXXX(i,paramter)提交参数。

在Java的测试类中，我们给account对象的id属性和firstName属性分别赋值为1和"tao"，当执行查询方法时，iBatis必须把这两个属性值传给Statement的SQL语句中对象的参数。这时怎么做到的呢？其实很简单，在这些类中都保存了在SqlMap配置文件初始化时解析Statement的所有必要的信息。

最终的SQL语句是：

select ACC_ID, ACC_FIRST_NAME as firstName, ACC_LAST_NAME as lastName from ACCOUNT where ACC_ID = ? and ACC_FIRST_NAME=?

#id:INTEGER#将被解析成JDBC类型是INTEGER，参数值取Account对象的id属性。#firstName#同样被解析成Account对象的firstName属性，而parameterClass="Account"指明了Account的类类型。注意#id:INTEGER#和#firstName#都被替换成了“?”，iBatis如何保证他们的顺序？在解析过程中，iBatis会根据“#”分隔符取出合法的变量名构建参数对象数组，数组的顺序就是在SQL中变量出现的顺序。接着iBatis会根据这些变量和parameterClass指定的类型创建合适的dataExchange和parameterPlan对象。在parameterPlan对象中按照前面的顺序保存了变量的setter和getter方法列表。

所以parameter的赋值就是根据在parameterPlan中保存的getter方法列表及传进来的account对象利用反射机制得到最终的SQL语句对应的参数值数组，再将这个数组按照指定的JDBC类型提交给数据库。以上这些过程可以用如下图所示的时序图清楚的描述。

在上图所示的8个步骤中，如果value值为空，则会设置preparedStatement.setNull(i, jdbcType)，如果在Statement中的变量没有设置jdbcType类型，则有可能会出错。