MyBatis 调用存储过程必须设置 statementType="CALLABLE"，否则数据库会拒绝执行；IN/OUT/INOUT 参数需用 #{param, mode=XXX} 显式声明，OUT 参数必须指定 jdbcType 和 resultMap；parameterType 必须为可变对象（如 Map 或带 setter 的 Bean），且参数顺序须与存储过程定义严格一致。
MyBatis 调用存储过程必须设 statementType="CALLABLE"
不设这个，MyBatis 默认当普通 SQL 执行，CALL 语句会被数据库拒绝或静默失败。尤其在 MySQL、Oracle 中表现不同：MySQL 可能报 ERROR 1312 (04000): PROCEDURE xxx can't return a result set in the given context；Oracle 则可能直接抛 ORA-06550 类错误。
实操建议：
-
<select>、<update>、<insert>、<delete>标签都支持statementType="CALLABLE"，别只盯着<select> - XML 中写法：
<select id="callProc" statementType="CALLABLE">{CALL proc_name(?, ?)} - 注解方式（@Select/@Update）无法指定
statementType，必须用 XML 或@SelectProvider配合StatementType.CALLABLE
IN/OUT 参数必须用 #{} + mode 显式声明
MyBatis 不会自动识别存储过程参数方向，#{param} 默认是 IN，但 OUT 或 INOUT 必须靠 mode 属性告诉它“这个参数要回填”。漏掉 mode，OUT 参数永远为 null，且无任何警告。
常见错误现象：Java 端拿到的 Map 或对象里，预期返回的字段始终是 null，而数据库日志确认过程已执行并赋值。
实操建议：
-
#{paramName, mode=IN}（可省略）、#{paramName, mode=OUT, jdbcType=VARCHAR}、#{paramName, mode=INOUT, jdbcType=INTEGER} -
jdbcType对 OUT 参数是强制的，尤其 Oracle；MySQL 宽松些，但建议统一写上 - 如果参数是结果集（比如 Oracle 的
REF CURSOR），要用resultMap+mode=OUT，不能用resultType
Oracle 存储过程返回游标需配 resultMap 和 jdbcType=ORACLECURSOR
MySQL 用 SELECT 直出结果集，Oracle 多数靠 OUT SYS_REFCURSOR 返回，MyBatis 必须知道这是个游标，否则解析失败或报 java.sql.SQLException: Invalid column type。
使用场景：分页查询、多结果集、动态列结构等不适合映射成固定 Java Bean 的情况。
实操建议：
- 参数定义：
#{cursor, mode=OUT, jdbcType=ORACLECURSOR, resultMap=yourResultMap} -
resultMap里字段名必须和游标中列名一致（注意大小写，Oracle 默认大写） - 别在同一个语句里混用
resultMap和resultType，会冲突 - MySQL 没有原生游标参数类型，若用
SELECT模拟，就不用jdbcType=ORACLECURSOR，也无需mode=OUT
调用后拿不到 OUT 参数？检查 parameterType 是否用了 Map 或自定义对象
MyBatis 要把 OUT 值写回 Java 对象，前提是这个对象可被修改。传原始类型（String、Integer）或不可变对象，OUT 值写不进去，也不报错——这是最隐蔽的坑。
性能影响：用 Map 最省事，但每次都要 map.get("key")；用自定义对象更安全，但得确保字段有 public setter 或 Lombok @Data。
实操建议：
- 务必用
Map或带 setter 的 Java Bean 作parameterType，别传String单值 - XML 中参数顺序必须和存储过程定义严格一致（尤其 Oracle，位置敏感）
- 调试时加日志：在存储过程里写入 DB 日志表，确认是否真执行了、OUT 参数是否被赋值
复杂点在于不同数据库对 CALL 语法、参数绑定、游标处理的差异远比文档写的多；最容易被忽略的是：没验证存储过程本身在数据库里是否能独立跑通，就急着连 MyBatis。
