必须写resultmap的典型场景有四种：字段名与属性名完全不匹配、查询含嵌套对象、需自定义类型转换、多表join后字段重名或需显式归属。
resultMap 标签什么时候必须写
不是所有查询都需要 resultMap。mybatis 能自动把列名（如 user_name）按驼峰规则映射到 Java 属性（如 userName），前提是开启了 mapUnderscoreToCamelCase=true，且字段和属性名能对上。
你必须写 resultMap 的典型场景：
• 数据库字段名和 Java 属性名完全不匹配（比如数据库是 usr_nm，Java 是 name）
• 查询结果包含嵌套对象（如 User 里有 Address 字段）
• 需要处理枚举、日期格式、空字符串转 NULL 等自定义转换
• 多表 JOIN 后字段重名或需要显式指定归属
id 和 result 子标签的区别与选型
id 和 result 都用于字段映射，但语义和用途不同：
• id 表示该字段是「唯一标识」，MyBatis 用它做一级缓存 key 和延迟加载的依据，**必须写在主键或逻辑主键字段上**
• result 是普通字段映射，没额外行为，适合大多数非主键字段
• 如果漏写 id，而查询又涉及延迟加载或二级缓存，可能出现数据错乱或 N+1 查询未生效
常见错误：
• 把联合主键里的某个字段用 result 写，导致 MyBatis 认为“无主键”，缓存失效
• 在 association 或 Collection 的子 resultMap 中忽略 id，导致嵌套对象无法正确去重
嵌套查询（association / collection）的性能陷阱
用 association 或 collection 做嵌套映射时，容易掉进两个坑：
• 直接写 select="xxx" 触发 N+1 查询：主 sql 查 10 条用户，就额外发 10 次地址查询
• 不设 fetchType="eager" 或没配全局 lazyLoadingEnabled=false，导致看似没查，实际调用 getter 时才懒加载，线上突然慢得离谱
更稳的做法：
• 优先用嵌套结果（resultMap + association 的 resultMap 属性），配合 JOIN 查询一次性拉回所有数据
• 如果必须用嵌套查询，确保外层 select 的 resultMap 里，association 的 column 参数只传必要字段（比如 column="user_id"），避免拼出超长 SQL
• 测试时打开 MyBatis 日志（logImpl=STDOUT_LOGGING），看实际执行了几条 SQL
column 属性到底填什么
column 不是数据库字段名的简单复制，而是「结果集中的列名」——也就是 SELECT 出来的别名（alias）。
例如：
• 错误写法：column="user_id"，但 SQL 里写的是 SELECT id AS user_id FROM users → 实际列名是 user_id，没问题
• 但若 SQL 是 SELECT u.id FROM users u，没 alias，那列名就是 id，此时 column="user_id" 就会映射失败，值为 null
• 多表 JOIN 时更危险：SELECT u.id, a.id FROM users u JOIN addresses a → 两个 id 列名冲突，必须用别名：u.id AS user_id, a.id AS addr_id，然后 column="user_id"
建议：
• 所有 JOIN 查询都显式用别名，避免依赖驱动返回的原始列名
• 在 association 的 column 里，多个参数用逗号分隔：column="user_id,tenant_code"
• 如果用到了 databaseId 或动态 SQL，确保 column 值在最终执行的 SQL 结果集中真实存在
字段映射看着简单，真正卡住人的往往是 column 对不上、id 漏写、或者嵌套时没意识到 SQL 已经变了。xml 里多一行 id，少一个别名，线上可能就差一条数据。