窗口函数计算账户余额必须严格按时间+唯一ID排序，期初余额需通过UNION ALL注入虚拟行，且须处理NULL值与数据库差异。
窗口函数必须按时间严格排序才能算对余额
账户余额是典型的累积值，依赖每笔交易的先后顺序。如果 ORDER BY 没写或写错（比如只按金额、没含时间戳），SUM() OVER() 会把所有行乱序累加，结果完全不可信。
常见错误现象：SELECT account_id, amount, SUM(amount) OVER (PARTITION BY account_id) AS balance —— 缺少 ORDER BY transaction_time，导致每个账户只返回一个总和，而非逐笔更新的实时余额。
- 必须用能唯一确定时序的字段，推荐组合：
ORDER BY transaction_time, transaction_id（防同一秒多笔） - 如果时间字段有
NULL，需显式处理：ORDER BY COALESCE(transaction_time, '1970-01-01')，否则NULL行可能被排在最前或最后，破坏逻辑 - PostgreSQL 和 MySQL 8.0+ 支持标准语法；SQLite 3.25+ 也支持，但旧版不支持窗口函数
初始余额不能硬编码进窗口函数
真实场景中，账户往往有期初余额（如开户时存入 1000 元），它不是某条交易记录，但必须作为累计起点。窗口函数本身无法“注入”这个初始值，得靠 SQL 逻辑拼接。
典型做法是把期初余额转成虚拟交易行，再和真实交易 UNION ALL：
SELECT account_id, transaction_time, amount FROM transactions UNION ALL SELECT account_id, '2024-01-01 00:00:00'::TIMESTAMP AS transaction_time, init_balance AS amount FROM accounts
之后再对合并结果做 SUM(amount) OVER (PARTITION BY account_id ORDER BY transaction_time)。注意：虚拟行的 transaction_time 必须早于所有真实交易时间，否则会错位。
- 别用
LAG()或FIRST_VALUE()尝试“补”初始值——它们只能取已有行的值，无法凭空生成起点 - 如果期初余额存在单独表里，务必确认
account_id关联准确，避免漏账户或多账户重复叠加
性能瓶颈常出在大分区 + 高频交易
当单个账户有数万笔交易，且你要查全部历史余额时，SUM() OVER() 的计算复杂度是 O(n)，数据库需扫描并累积每一行。此时即使加了索引，排序和累计仍吃 CPU 和内存。
- 关键优化：确保
(account_id, transaction_time)有联合索引，让排序走索引扫描，避免临时文件排序 - 如果只查“最新余额”，别用窗口函数全量计算——直接
SELECT account_id, SUM(amount) FROM transactions GROUP BY account_id更快 - 高频写入场景（如每秒百笔），考虑用物化视图或应用层缓存余额，避免每次查询都重算
MySQL 8.0 与 PostgreSQL 的 NULL 处理差异要留意
同一笔负向交易（如支出 -50），在不同数据库里参与累计时，对 NULL 值的默认行为不一致：PostgreSQL 把 NULL 当作“跳过”，而 MySQL 8.0 默认将 NULL 视为 0 参与求和（取决于 SQL mode）。这会导致余额偏差。
- 显式过滤或转换：
COALESCE(amount, 0)是最安全写法，强制统一语义 - 检查你的数据库配置：
SELECT @@sql_mode（MySQL）或SHOW SESSION VARIABLES LIKE 'sql_mode'，确认是否启用了STRICT_TRANS_TABLES - 测试时故意插入一条
amount IS NULL的记录，观察余额是否突变，比看文档更直接
窗口函数本身不难，但账户余额这种业务逻辑，错一个排序、漏一行期初、忽略一个 NULL，结果就全盘作废。实际跑之前，先拿三笔数据手算一遍，比调十次 SQL 更省时间。
