第一页只有十张订单，SQL 却执行很多次；直接把明细一起抓取，又可能破坏分页结果。
本文使用Hibernate ORM 4.3、JDK 7 与独立关系数据库，代码为映射或调用片段。ORM（对象关系映射）连接对象生命周期与数据库行，但不会取消事务、索引和并发约束。观察对象属性的同时，也需要查看真正发出的 SQL 与提交边界。
1. 从现象推到机制
逐条访问关联会触发额外查询，形成 N+1。集合连接抓取可能把一张订单扩成多行，数据库分页作用在连接结果上时，根实体数量可能不符合预期。需要区分按订单分页与按明细行分页。
图中的四个节点分别表示订单分页、关联读取、视图组装、结果核对。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
可先稳定分页取订单编号，再批量读取所需明细并组装视图。比较总查询数、根实体数量和返回数据量，而不只看一次查询耗时。
1
2
3
4
1. 查询一页订单 id，使用稳定排序
2. 按这一页 id 批量查询明细
3. 按 id 组装展示对象
4. 总数查询与分页口径保持一致
先建立只有订单与明细的演示模型，启用 SQL 日志并准备少量固定数据。会话、事务和连接分别关闭；读取结果正确之外，还要观察语句数量和异常发生阶段。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 每张订单访问一次懒集合 | 查询次数会随订单数增长 |
| 一对多连接后直接分页 | 可能出现根订单数量失真 |
| 先分页编号再批量加载 | 可保留明确的根实体分页语义 |
对照 1：每张订单访问一次懒集合
查询次数会随订单数增长。观察时记录同一次请求中的 SQL 总数。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：一对多连接后直接分页
可能出现根订单数量失真。观察时记录连接行数与去重后的订单数。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：先分页编号再批量加载
可保留明确的根实体分页语义。观察时记录排序与两次查询的数据一致性。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
两阶段读取在并发更新下也可能看到不同快照。是否需要更强一致性，取决于页面用途与事务隔离，不应把它描述成无条件最优。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“先分页编号再批量加载”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
