xbatis 1.10.15 发布：升级 ORM 前，先看生成的 SQL
内容提要
xbatis 1.10.15 发布，作者提醒升级 ORM 需谨慎：接口不变不代表 SQL 不变，应对比升级前后的 SQL 与执行计划，核对空值、分页、租户过滤等约束；“部分兼容 MyBatis 3.6.0”需查完整说明确认边界。建议先固定底层依赖单独升级并分开记录变更，选读多写少的内部查询试点并留开关，观察慢查询与连接占用，写操作重点验证条件与事务。
延伸解读
接口不变，SQL 可能已变
文章提醒，ORM 升级后业务接口返回字段可能不变、测试也可能全绿，但生成的查询条件组织方式可能改变，进而影响数据库执行计划。对连表多、分页重的列表接口，应保留升级前后的 SQL，用接近业务分布的数据对比执行计划，并核对空值条件、分页总数、租户过滤和逻辑删除等既有约定是否被绕开。
“部分兼容”需要查边界
发布摘要提到“提前部分兼容 MyBatis 3.6.0”，但未展开具体修复项和兼容范围。文章建议按字面理解：有兼容工作，但边界仍需查完整发布说明，确认项目使用的 MyBatis 版本是否在支持范围内。摘要没给答案的地方不适合靠猜，也不应把代码缩减比例直接当成项目收益。
升级顺序：先固定底层依赖
保守做法是先固定底层依赖，只升级 ORM 包，在测试环境核对行为；若需同时调整 MyBatis，应分开保留变更记录，方便定位差异。不要顺手把连接池和数据库驱动一起换掉，否则线上出现慢查询时，多个依赖同时变化会拉长排查时间。
试点选读多写少，写操作重点验条件与事务
普通团队可挑一个读多写少、出错后容易停用的内部查询做试点，保留现有实现并设置明确开关，同时观察请求耗时、数据库慢查询和连接占用。写操作要更谨慎：批量更新是否带齐条件、事务是否仍按原边界提交，最好用失败用例验证。能直接查看 SQL、沿用现有日志定位故障，比调用形式漂亮更有用。
Q&A
xbatis 1.10.15 升级时，为什么不能只看 Java 接口是否兼容？
因为接口不变不代表生成的 SQL 不变。ORM 升级可能改变查询条件的组织方式，进而影响数据库执行计划。即使业务接口返回相同字段、测试全绿，连表多、分页重的列表接口也可能出现性能变化，所以需要对比升级前后的 SQL 和执行计划。
升级 xbatis 前，应该重点核对哪些 SQL 相关约束？
应核对空值条件处理、分页总数是否一致，以及服务依赖的租户过滤或逻辑删除等约束是否在替换查询写法时被绕开。建议保留升级前后的 SQL，用接近业务分布的数据跑一遍。
xbatis 1.10.15 声称“部分兼容 MyBatis 3.6.0”，升级时该如何理解这个声明？
“部分兼容”意味着有兼容工作但边界需要查证。准备升级前应先读完整发布说明，确认项目使用的 MyBatis 版本是否落在支持范围内，不能仅凭摘要猜测。
升级 xbatis 时，依赖调整的顺序有什么建议？
建议先固定底层依赖，只升级 ORM 包，在测试环境核对行为。若需同时调整 MyBatis，应分开保留变更记录以便定位差异。不要顺手把连接池和数据库驱动也一起换掉，否则线上出慢查询时难以排查。
想试点 xbatis 新版本，应该选什么样的业务链路？
建议挑一个读多写少、出错后容易停用的内部查询做试点。保留现有实现，给新实现安排明确开关。观察请求耗时的同时，也要看数据库侧的慢查询和连接占用，因为应用层平均响应时间正常不代表数据库没有多干活。
升级 xbatis 后，写操作需要额外验证什么？
写操作要重点验证批量更新是否带齐条件、事务是否仍按原来的边界提交，最好用失败用例去验证。对小团队来说，最怕代码看着短了，出问题时却没人能解释实际执行了什么。
