MySQL 8.0+才支持SUM() OVER()，低版本会报语法错误；必须显式写ORDER BY，否则报错；NULL值需用COALESCE处理；性能优化需为PARTITION BY和ORDER BY字段建联合索引。
MySQL 8.0+ 才能用 SUM() OVER()
如果你的 MySQL 版本低于 8.0，SUM() OVER() 直接报错：ERROR 1064 (42000): You have an error in your SQL syntax。这不是写法问题，是版本硬限制。5.7 及更早版本不支持任何窗口函数，强行改写成自连接或变量计算不仅慢，还容易在排序不稳定时出错。确认版本最简单的方式是执行：SELECT VERSION(); —— 输出带 -log 或小数点后两位（如 8.0.33）才可靠。
ORDER BY 在 OVER() 里不能省
累积求和必须明确按什么顺序累加，否则结果无意义。漏写 ORDER BY 会导致语法错误：ERROR 3589 (HY000): Window '<window_name>' with no ORDER BY is not allowed for aggregate window functions</window_name>。即使表有主键或索引，MySQL 也不会自动推断排序依据。常见错误写法：SUM(amount) OVER(PARTITION BY user_id) —— 缺少 ORDER BY，必须补全，例如：SUM(amount) OVER(PARTITION BY user_id ORDER BY created_at)。注意：如果 created_at 有重复值，建议加上二级排序字段（如 id）避免非确定性结果。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
累计值为 NULL？检查原始数据是否含 NULL
SUM() 遇到 NULL 会跳过，但若某行 amount 是 NULL，它不会参与累加，后续行的累计值仍正常；但如果第一行就是 NULL，累计值从第二行才开始非空。更隐蔽的问题是：当 OVER() 的 PARTITION BY 分组内所有值都是 NULL，整组累计结果全为 NULL。验证方法：先查 SELECT id, amount FROM orders WHERE amount IS NULL LIMIT 5;。修复建议统一用 COALESCE(amount, 0) 替代原始字段，避免逻辑断裂。
大数据量下性能明显变慢？注意执行计划里的 Using filesort
窗口函数依赖排序，MySQL 会为每个 OVER() 子句触发一次排序操作。如果 ORDER BY 字段没有索引，执行计划中会出现 Using filesort，数据量超 10 万行后延迟陡增。优化路径很直接：给 PARTITION BY + ORDER BY 字段建联合索引。例如按用户分组、按时间累加，就建：CREATE INDEX idx_user_time ON sales (user_id, created_at);。注意索引顺序必须和 OVER() 中一致，反过来（created_at, user_id）无法生效。
