GROUP BY后查不到非聚合字段的原始值是因SQL标准要求SELECT列须在GROUP BY中或为聚合结果；窗口函数如ROW_NUMBER()可按PARTITION BY分组排序取最新行，但需注意NULL分组、排序确定性等细节。
为什么 GROUP BY 后查不到非聚合字段的原始值
因为标准 SQL 要求 SELECT 列要么是 GROUP BY 的字段，要么是聚合函数（如 MAX()、COUNT()）的结果。直接写 SELECT id, name, COUNT(*) FROM t GROUP BY type 会报错：column "id" must appear in the GROUP BY clause or be used in an aggregate function。
这不是数据库“限制”，而是语义问题：同一组里有多个 id，数据库不知道你要哪一条。
窗口函数能绕过这个限制——它不改变行数，只是给每行“附加工具计算结果”：
-
OVER (PARTITION BY type)表示按type分组计算，但保留原表每一行 - 每行仍能访问自己的
id、name，同时拿到该type组的统计值 - 常见误用：把
OVER当成GROUP BY的替代品去“去重”或“收缩结果集”，其实它完全不收缩
怎么用 ROW_NUMBER() / RANK() / FIRST_VALUE() 配合 PARTITION BY 取分组内某行数据
想在分组中取“每个 type 最新一条记录”？不能靠 GROUP BY + MAX(created_at) 再关联回去——太绕且易错。直接用窗口函数定位：
-
ROW_NUMBER() OVER (PARTITION BY type ORDER BY created_at DESC)：给每组内按时间倒序编号，1 就是最新那条 -
FIRST_VALUE(id) OVER (PARTITION BY type ORDER BY created_at DESC)：直接取每组最新记录的id（注意：需搭配ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING才稳定，否则默认窗口可能只到当前行） - 别用
RANK()取“第一条”——并列时会返回多个 1，而ROW_NUMBER()强制唯一排序
示例（取每组最新完整行）：
SELECT * FROM (
SELECT *,
ROW_NUMBER() OVER (PARTITION BY type ORDER BY created_at DESC) AS rn
FROM products
) t WHERE rn = 1;聚合函数加 OVER 和不加 OVER 的行为差异
COUNT(*) 和 COUNT(*) OVER (PARTITION BY type) 看似一样，实际天差地别：
- 不加
OVER：必须配合GROUP BY，结果行数变少，每行代表一个分组 - 加
OVER：不压缩行数，每行都显示自己所属分组的总行数，可用于“这组一共几条？我排第几？”这类判断 - 性能上，窗口函数通常比自连接或子查询更高效，但大数据量时
ORDER BY子句（尤其涉及多列排序）会显著拖慢，能不排序就不排 - PostgreSQL 支持
COUNT(*) FILTER (WHERE status = 'active')配合OVER，但 MySQL 8.0+ 才支持FILTER，旧版得用SUM(IF(...))
MySQL 5.7 或旧版 PostgreSQL 怎么模拟 PARTITION BY 效果
没窗口函数？别硬套，用关联子查询或变量法，但要注意陷阱：
- MySQL 5.7 可用用户变量：
@rownum := IF(@prev = type, @rownum + 1, 1) AS rn，但必须严格按PARTITION BY字段和ORDER BY字段双重排序，否则变量状态错乱 - 通用安全法：用左连接 + 子查询统计，例如
(SELECT COUNT(*) FROM t2 WHERE t2.type = t1.type)，但 N+1 查询风险高，数据量大时明显变慢 - 真正要命的是 NULL 值：所有
PARTITION BY字段为NULL的行会被归为同一组，而变量法或子查询容易漏掉这个逻辑，导致计数偏差
如果业务逻辑本身允许降级（比如只要“近似最新”），优先考虑应用层分批处理，而不是在 SQL 里硬凑兼容写法。
窗口函数不是银弹，PARTITION BY 的边界含义、ORDER BY 的确定性、空值分组规则——这些细节一旦忽略，结果就静悄悄地错。
