rollup不能直接生成中国式报表，它仅提供多级汇总数据，不处理分页、页眉页脚、跨表头合并等格式逻辑；需sql层用rollup聚合、应用层控制分页与排版。
ROLLUP 本身不能直接实现中国式复杂报表——它只负责生成多级汇总行，不处理页眉/页脚、固定行数分页、跨表头合并、动态口径切换或审批流。想靠一条 GROUP BY ROLLUP 语句打出带“第3页/共8页”“每页10行明细+小计”“主表抬头+子表滚动”的标准中国式打印报表，注定失败。
但 ROLLUP 是其中关键一环：它高效提供分组小计与总计，是报表后端数据准备阶段不可替代的聚合工具。真正落地，必须分层协作——SQL 层用 ROLLUP 做干净聚合，应用层（如活字格、自研报表服务）做格式控制与分页逻辑。
为什么直接用 ROLLUP 无法生成完整中国式报表
常见误解是把 ROLLUP 当成“报表生成器”。实际上它只是 SQL 聚合增强语法，输出仍是扁平结果集：
-
ROLLUP(A, B, C)产出的是带NULL占位符的多层级汇总行，没有页概念、无固定行高、不区分页眉/页脚数据 - 中国式报表要求“每页显示10条明细 + 页尾小计 + 页码基于分组内统计”，这需要在应用层识别
GROUPING_ID()值、按物理行序切片、注入占位空行——ROLLUP不参与这些 - 多口径指标（如“销售额”按下单/回款/开票三套统计）需不同
ROLLUP子查询联合或动态拼接，不能靠单个ROLLUP表达
ROLLUP 在中国式报表中的真实定位：后端聚合加速器
它解决的是“数据怎么算得又快又准”，不是“怎么排版打印”。典型配合方式：
- 主子表结构下，用
ROLLUP对子表明细预聚合：比如按(订单号, 产品类目)汇总金额，再ROLLUP得到每单小计、类目小计、全局合计 - 结合
GROUPING()和GROUPING_ID()区分汇总层级，避免NULL与真实空值混淆。例如：GROUPING(产品类目) = 1表示该行是订单级小计，不是类目缺失 - 和窗口函数嵌套使用：先
ROLLUP出各级汇总，再用ROW_NUMBER() OVER (PARTITION BY 订单号 ORDER BY GROUPING_ID())标记分组内序号，供上层分页逻辑消费 - 性能上，
ROLLUP比等价的UNION ALL快 3–5 倍（Oracle 19c 优化器对ROLLUP有专用执行计划），尤其当分组列 > 2 时优势明显
实际组合方案：ROLLUP + 应用层分页控制
以“每页10条订单明细 + 每页底部显示本单小计 + 页码按订单分组内计数”为例：
- SQL 层：用
SELECT 订单号, 产品类目, SUM(金额), GROUPING_ID(订单号, 产品类目) gid FROM 订单明细 GROUP BY ROLLUP(订单号, 产品类目)获取原始聚合数据 - 应用层（如活字格页面报表）：设置表格扩展区域高度 = 10 行 × 单行高度；通过
{&PageNumberInSection}和{&TotalPagesInSection}渲染页码；用gid = 1的行识别订单小计，插入到每页末尾 - 注意陷阱：Oracle 19c 中
ROLLUP结果默认无序，必须显式加ORDER BY 订单号, GROUPING_ID(), 产品类目，否则分页时小计可能错位 - 若需“不足10行补空白”，
ROLLUP不提供该能力，需应用层根据每组明细行数补NULL行或渲染空单元格
ROLLUP 输出的“逻辑聚合结果”，映射到“物理打印页面”上——这个映射规则（几行一页、哪行插小计、页码怎么重置）必须由报表引擎或业务代码明确定义，ROLLUP 只管把数字算对。
