余额计算必须用SUM() OVER()，因其能严格按ORDER BY定义的唯一顺序（如trans_time, trans_id）持续累加，避免LAG()/LEAD()因排序不稳定或NULL导致的错位；需预处理空值、过滤无效状态，并确保排序字段有复合索引以保障性能与精度。
余额计算必须用 SUM() OVER()，不能用 LAG() 或 LEAD()
窗口累计求和是唯一可靠方式。用 LAG() 手动累加会因排序不稳定或空值中断导致余额错位，尤其在多笔同时间戳、无唯一排序键的流水表中极易出错。SQL Server 2022 的 SUM() OVER() 支持完整 ORDER BY + ROWS UNBOUNDED PRECEDING，能严格按业务顺序（如交易时间+流水号）持续累加。
- 必须显式指定
ORDER BY，且该列组合需能唯一确定每行顺序（推荐：trans_time, trans_id） - 避免只用
ORDER BY trans_time—— 若存在毫秒级相同时间的多笔交易，SQL Server 可能任意排序，余额结果不可复现 - 初始余额要作为第一行数据插入，或用
ISNULL(SUM(...) OVER(...), @init_balance)补齐（但更推荐显式插入首行）
处理负值与空值：先清洗再计算，别指望窗口函数自动容错
资金流水常见负向支出（如退款、扣款），SUM() OVER() 天然支持正负混合累加，但空值会直接中断整个窗口聚合 —— 只要某行 amount 是 NULL，从该行起所有后续余额全为 NULL。
- 务必用
ISNULL(amount, 0)或COALESCE(amount, 0)预处理金额列 - 若存在状态字段（如
status = 'cancelled'），应在WHERE中提前过滤，而不是靠CASE WHEN在窗口内转成 0 —— 后者仍占用排序位置，可能影响“有效余额”的业务语义 - 不要用
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW显式写出来，默认行为就是它，冗余写法易引入拼写错误
性能关键：排序字段必须有索引，且覆盖查询所需列
窗口函数的 ORDER BY 是性能瓶颈所在。SQL Server 2022 虽优化了窗口执行计划，但若排序列无索引，每次查询都会触发大排序（Sort Spill 到 tempdb），流水表超 10 万行后延迟明显。
- 建立复合索引：
CREATE INDEX IX_trans_flow_sort ON dbo.trans_flow (trans_time, trans_id) INCLUDE (amount) - 避免在
ORDER BY中使用函数（如CONVERT(DATE, trans_time)），会导致索引失效 - 如果业务允许按日分区计算余额，可加
WHERE trans_time >= '2024-01-01'配合分区表剪枝，比单靠索引更高效
导出到应用层时注意 DECIMAL 精度截断
SQL Server 中 amount 常用 DECIMAL(18,2)，但窗口计算后的余额列若未显式声明精度，可能被隐式转为 NUMERIC(38,6) 等类型，某些 ORM（如 Entity Framework）或报表工具会截断小数位，导致显示为 100.000000 或丢失精度。
- 强制转换余额列：
CAST(SUM(ISNULL(amount,0)) OVER (ORDER BY trans_time, trans_id) AS DECIMAL(18,2)) AS balance - 不要依赖客户端格式化 —— 余额是精确数值，不是展示需求，精度必须在 SQL 层锁定
- 测试时用
SELECT balance, SQL_VARIANT_PROPERTY(balance, 'Precision'), SQL_VARIANT_PROPERTY(balance, 'Scale')验证实际类型
datetime2 字段，却没意识到高并发下毫秒级重复极常见，不加 trans_id 或序列号辅助排序，余额结果在不同执行中可能不一致。 
