本文详解如何通过sql窗口函数准确计算员工往来结算的期初余额、变动额与期末余额，生成按时间排序的动态结算流水报表。
本文详解如何通过sql窗口函数准确计算员工往来结算的期初余额、变动额与期末余额，生成按时间排序的动态结算流水报表。
在员工往来结算管理中，真实反映每一笔交易对账户余额的影响至关重要。理想报表需包含三列：期初余额（Start Balance）、当期变动（Change） 和 期末余额（Final Balance），且必须严格按交易时间（created_at）升序排列，确保余额累计逻辑正确。
核心难点在于：期初余额 = 上一笔交易的期末余额，而首笔交易的期初余额恒为 0。这本质上是一个“累计求和 + 前移一位”的计算问题，应使用 SUM() OVER() 窗口函数配合 LAG() 实现，而非对原始表直接 GROUP BY id —— 后者会破坏事务粒度，导致聚合错误（如原查询中 GROUP BY id 与未聚合字段混用，语法不合规且语义错误）。
✅ 正确解法如下（兼容 MySQL 8.0+、PostgreSQL、SQL Server、Oracle）：
SELECT
employee_id,
COALESCE(
LAG(running_total) OVER (
PARTITION BY employee_id
ORDER BY created_at, id -- 推荐加入id防时间重复时排序不稳定
),
0
) AS start_balance,
amount AS change,
SUM(amount) OVER (
PARTITION BY employee_id
ORDER BY created_at, id
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
) AS final_balance,
reason,
created_at
FROM settlement_settlement
WHERE employee_id = ? -- 替换为具体员工ID，如 101
ORDER BY created_at, id;? 关键说明：
-
PARTITION BY employee_id确保余额计算仅限于目标员工，避免跨员工干扰； -
LAG(running_total)中的running_total即当前行的累计和（final_balance），LAG将其下移一行即得上一行的期末余额 → 本行期初余额； -
COALESCE(..., 0)将首行LAG返回的NULL安全转为0； -
ORDER BY created_at, id防止同一时间多笔交易导致窗口排序不确定； -
切勿使用
GROUP BY id：原始表每行已是独立交易记录，无需分组；强行分组会丢失明细，且SUM(amount)在未分组字段上非法。
⚠️ 注意事项：
- 若使用 MySQL 5.7 或更早版本（不支持窗口函数），需改用自连接或变量方式模拟，但可读性与性能显著下降，强烈建议升级至 MySQL 8.0+；
- 生产环境务必为
(employee_id, created_at, id)建立联合索引，大幅提升窗口函数排序效率； -
amount字段应定义为DECIMAL(p,s)类型（如DECIMAL(12,2)），避免浮点数精度误差影响财务数据准确性。
该方案输出结果与需求表格完全一致：逐行展示余额演进过程，逻辑清晰、性能可靠，是财务类结算报表的标准实践。
