能，而且效果显著——但前提是OVER子句写对、索引跟上；ROW_NUMBER()替代自连接求每组最新记录，仅扫描一次表，需PARTITION BY分组字段+ORDER BY时间与唯一列保序，并外层WHERE rn=1过滤。
能，而且效果显著——但前提是 OVER 子句写对、索引跟上，否则性能可能更差。
ROW_NUMBER() 替代“每组取最新一条”的自连接
传统写法用 LEFT JOIN 或相关子查询找每个用户的最新订单，执行计划里常出现 Using temporary; Using filesort，数据量一过百万就明显变慢。窗口函数只扫一次表，按 PARTITION BY user_id ORDER BY create_time DESC, order_id DESC 分区排序标号即可。
- 必须先 WHERE 过滤（如
status = 'paid'），再套窗口函数；不然在全量数据上计算，浪费资源 -
PARTITION BY字段要和业务分组维度严格一致（比如用user_id，别用user_name） -
ORDER BY必须含唯一列保序，否则相同时间戳下ROW_NUMBER()分配可能不一致 - 外层一定要加
WHERE rn = 1，窗口函数本身不减少行数
SELECT user_id, order_id, create_time
FROM (
SELECT *,
ROW_NUMBER() OVER (
PARTITION BY user_id
ORDER BY create_time DESC, order_id DESC
) AS rn
FROM user_orders
WHERE status = 'paid'
) t
WHERE rn = 1;SUM() OVER 配合 ROWS 框架替代滚动累计自连接
算“最近7天销售额累计”，老办法要 LEFT JOIN 同一张表7次，SQL 膨胀、难维护、索引难利用。窗口函数一行搞定，但关键在帧定义方式。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 必须带
ORDER BY，否则SUM() OVER (PARTITION BY ...)算的是整组总和，不是累计值 - 推荐用
ROWS而非RANGE：前者按物理行偏移，稳定可预期；后者按值范围，遇到重复日期会把同一天所有行都拉进来，结果膨胀 - 日期有缺失时，
ROWS BETWEEN 6 PRECEDING AND CURRENT ROW是按行数滑动，不是按日历天数；真要按自然日滚动，得先用GENERATE_SERIES()补全日期再 JOIN - 避免
RANGE BETWEEN INTERVAL '7 day' PRECEDING—— MySQL 8.0 不支持这种写法，别被 PostgreSQL 文档误导
SUM(sales) OVER ( PARTITION BY store_id ORDER BY sale_time ROWS BETWEEN 6 PRECEDING AND CURRENT ROW )
LAG()/LEAD() 替代自连接做环比/同比计算
查“本月 vs 上月销售额”，老办法是 sales s1 LEFT JOIN sales s2 ON s2.month = DATE_SUB(s1.month, INTERVAL 1 MONTH)，JOIN 开销大、顺序不可控。用 LAG() 在一次有序扫描中就拿到前一行值。
- 必须配合
ORDER BY，否则“前一行”无意义；日期字段精度不够（如只有秒级）时，得补二级排序字段，如ORDER BY sale_date, id -
LAG(sales)对首行返回NULL，直接sales - LAG(sales)会导致整列变NULL；应显式处理：sales - COALESCE(LAG(sales), 0)或更合理的sales - COALESCE(LAG(sales), sales) - 别在 WHERE 中引用
LAG()结果，窗口函数在 WHERE 之后执行，必须套子查询或 CTE 才能过滤
容易被忽略的硬性限制和性能陷阱
窗口函数不是语法糖，MySQL 8.0 解析器看到 ROW_NUMBER() 就检查后面有没有 OVER，漏写直接报 ERROR 1064；而性能问题往往藏在索引和执行路径里。
-
PARTITION BY和ORDER BY字段上没联合索引（如(dept_id, salary)），就会触发filesort，比带索引的自连接还慢 - 误写
ROW_NUMBER() OVER (PARTITION BY dept_id)（缺ORDER BY）—— MySQL 不报错但结果不可复现，尤其并发查询时 - 在 SELECT 里混用
GROUP BY和窗口函数，要么语法报错，要么逻辑错乱；窗口函数输出行数恒等于输入行数，GROUP BY会压缩行数，二者语义冲突 - 确认版本：执行
SELECT VERSION();，低于 8.0 会报ERROR 1305 (42000): FUNCTION does not exist
