MyBatis查视图与查表无本质区别，关键在于字段名、类型、大小写、权限及分页逻辑需严格对齐：①优先用resultMap显式映射下划线转驼峰；②避免resultType自动匹配导致空值或类型异常；③parameterType须与接口参数类型一致；④视图含GROUP BY/窗口函数时分页易失效，应推条件至底层或子查询包装；⑤上线前须用应用账号直连验证视图可查。
MyBatis 查询视图和查普通表几乎没区别，只要数据库里视图存在、字段可读、权限正确，就能直接映射 —— 关键不是“能不能”，而是“怎么写才不踩坑”。
视图字段与 resultType 不匹配导致空结果或 ClassCastException
视图返回的字段名、类型、大小写敏感性，必须和 resultType 或 resultMap 定义严格对齐。尤其常见于数据库字段带下划线（如 user_id）而 Java 实体类用驼峰（userId），MyBatis 默认不会自动转换。
- 优先用
resultMap显式映射，避免依赖自动匹配：<resultmap id="ContactEarnsResultMap" type="com.example.ContactEarns"><id property="id" column="id"></id><result property="title" column="title"></result><result property="tradeTime" column="trade_time"></result><result property="tradeAmount" column="trade_amount"></result></resultmap>
- 若用
resultType="java.util.Map"，字段名会原样作为 key，但注意 PostgreSQL/Oracle 视图列名默认大写或双引号包裹，MySQL 默认小写，实际 key 名需以日志或调试器确认 - 不要假设视图字段类型和表一致：比如视图中
COALESCE(amount, 0)可能返回DECIMAL，但实体类用了Integer就会报类型转换异常
Mapper 接口方法参数类型与 XML 中 parameterType 不一致
视图查询通常带 WHERE 条件，但 parameterType 写错会导致参数根本传不进 SQL，最终查出全量数据或报空指针。
-
parameterType必须和接口方法签名一致：如果方法是List，XML 中就得写getDetail(Long userId) parameterType="java.lang.Long"（不能漏掉java.lang.，尤其在老版本 MyBatis 中） - 使用注解方式更稳妥：
@Param("userId") Long userId，XML 中用#{userId}即可，不用管parameterType - 视图本身不支持 INSERT/UPDATE，所以别在视图查询语句里误加
视图跨库或含函数导致分页失效
用 RowBounds 或 PageHelper 分页时，如果视图定义里含 GROUP BY、窗口函数或跨库 JOIN，MySQL/Oracle 的物理分页可能被绕过，变成内存分页 —— 数据量一大就 OOM。
- 检查视图 DDL：
SHOW CREATE VIEW v_contacts_earn，确认是否含不可下推的逻辑 - 避免在视图里做聚合后分页；应把分页条件尽量“推入”视图底层表（例如把
WHERE user_id = ?放在视图定义内部，而不是查视图时再加） - PostgreSQL 视图默认不支持
LIMIT/OFFSET下推，建议改用子查询包装：SELECT * FROM (SELECT * FROM v_contacts_earn WHERE user_id = #{userId}) t LIMIT #{limit} OFFSET #{offset}
最易被忽略的是视图权限 —— 开发环境有 DBA 授了 SELECT，上线后账号只给了表权限，视图查不到却无明确报错，只会返回空集合。上线前务必用应用账号直连数据库执行 SELECT * FROM your_view_name LIMIT 1 验证。
