FreeSql中UnionAll分页查询的注意事项

在使用FreeSql进行复杂查询时，UnionAll操作与分页查询的组合可能会产生一些意料之外的结果。本文将通过一个实际案例，分析这种组合查询可能产生的问题及其解决方案。

问题现象分析

在FreeSql中，当开发者尝试将UnionAll与分页查询结合使用时，可能会遇到以下情况：

1. 第一页查询正常执行，但结果集可能不符合预期
2. 后续分页查询时，SQL语句结构发生变化，导致结果异常
3. 分页总数计算不准确

问题根源

问题的核心在于UnionAll操作与分页查询的执行顺序。在上述案例中，开发者在一个UnionAll查询的两个部分都应用了分页逻辑：

// 第一部分查询
.FromQuery(realTimeAiEventValueSelect,callRecordSelect)
// ...其他条件...
.Page(pageIndex,pageSize)

// 第二部分UnionAll查询
.UnionAll(_reportRepository.FreeSql.Select<CallRecordEntity>()
    // ...其他条件...
    .Page(pageIndex,pageSize))

这种写法会导致SQL生成时，每个UnionAll的部分都单独应用了分页逻辑，而不是对整个联合结果集进行分页。

正确使用方式

正确的做法应该是：

1. 保持UnionAll各部分查询完整，不单独分页
2. 在整个UnionAll查询完成后，再应用分页逻辑

修改后的代码结构应该是：

var query = _reportRepository.FreeSql.Select<RealtimeMonitorEntity>()
    .FromQuery(realTimeAiEventValueSelect,callRecordSelect)
    // ...第一部分查询条件...
    .WithTempQuery(...)
    
    .UnionAll(_reportRepository.FreeSql.Select<CallRecordEntity>()
        // ...第二部分查询条件...
        .WithTempQuery(...))
    
    // 统一分页
    .Count(out var totalCount)
    .Page(pageIndex,pageSize)
    .ToListAsync();

技术原理

FreeSql在处理分页查询时，会根据调用链的顺序生成相应的SQL语句。当在UnionAll内部使用Page方法时，它会为每个部分生成独立的分页逻辑，这通常不是开发者想要的效果。

正确的分页应该作用于整个联合查询的结果集上，这样才能保证分页结果的准确性和一致性。

最佳实践建议

1. 避免在UnionAll的各个部分单独使用分页
2. 确保分页逻辑应用于整个查询的最后阶段
3. 对于复杂查询，可以先构建完整查询再分页
4. 测试不同分页情况下的SQL生成，确保符合预期

通过遵循这些原则，可以确保UnionAll分页查询的正确性和性能。