需拆解为参数动态注入、SQL结构化编排、并发抓取控制和Phaser阶段感知四环节；通过Phaser阶段ID绑定上下文参数，按模板动态组装嵌套SQL，分阶段隔离调度，并以onAdvance驱动后续编排与参数清理。
这个问题涉及多个技术层的协同设计，实际落地时需拆解为“参数动态注入”、“SQL 结构化编排”、“并发抓取控制”和“Phaser 阶段感知”四个核心环节。关键不在于写一个大 SQL，而是在后端服务中构建可感知阶段状态、按需生成并调度嵌套行列查询的执行管道。
用 Phaser 阶段 ID 绑定参数上下文
Phaser 本身不传递业务参数，需在进入每个阶段前，将手动定义的阶段参数（如 region_id=shanghai、batch_size=500、row_depth=3）存入线程绑定上下文或阶段专属缓存（如 ConcurrentHashMap<Integer, Map<String, Object>>，key 为 phase number）。后续 SQL 构建逻辑通过当前 Phaser.getPhase() 实时查表获取对应参数，避免硬编码或全局配置污染。
嵌套行列 SQL 按阶段模板动态组装
不手写固定 SQL，而是为每类阶段预设结构化模板：
-
行列展开型（如 region → dept → user）：用参数 row_depth=2 控制 JOIN 层数，模板含占位符
{depth_1_table}、{depth_2_cond}，运行时替换为departments和d.parent_id = r.id -
聚合嵌套型（如统计各区域下部门平均用户数）：用 agg_mode=count_avg 触发子查询包裹，外层 SELECT 套用
(SELECT AVG(...) FROM (...)) AS dept_avg - 所有模板使用 PreparedStatement 兼容语法，参数值统一走 ? 占位，由阶段上下文提供实际值列表
并发抓取按阶段粒度隔离调度
不同 Phaser 阶段可能对应不同数据源或负载特征，不能共用同一连接池：
- 为每个阶段分配独立的 ScheduledExecutorService（命名如
fetch-pool-phase-2），线程数由 concurrent_threads 参数指定 - 行列嵌套查询拆解为“主键批切片 + 并行子查询”：先查出 top-level ID 列表（如 1000 个 region_id），再按 batch_size 分组，每组提交至对应阶段线程池，子查询自动继承该阶段的 SQL 模板与参数
- 用 CompletableFuture.allOf() 聚合结果，失败项记录 phase_id + batch_id，供重试定位
阶段完成态驱动下一步 SQL 编排
Phaser 的 onAdvance() 回调是关键枢纽：
- 在回调中检查 phase number，若 phase == 2 完成，则触发 phase 3 的 SQL 模板加载，并把 phase 2 的聚合结果（如 {shanghai=42, beijing=38}）注入 phase 3 的参数上下文
- 支持条件跳过：如 skip_if_empty=true 且上阶段返回空结果集，则直接 advance 到下一 phase，不生成任何 SQL
- 所有阶段参数、SQL 日志、耗时均打标 phase-{n}，便于在 ELK 或 Prometheus 中按阶段分析性能瓶颈
不复杂但容易忽略的是阶段参数的生命周期管理——必须在 phase advance 后主动清理已过期参数，否则跨阶段污染会导致 SQL 生成错乱。实际项目中建议封装一个 PhaseScopedParamStore 工具类，配合 Phaser 的注册/抵达钩子自动托管。
