要用窗口函数 row_number() 按分类取销售额最高的完整订单详情，需先用 row_number() over (partition by category order by sales desc) 为每类编号，再筛选编号为1的行；若存在并列最高值且需全部返回，则改用 rank() 或 dense_rank()。
用窗口函数 ROW_NUMBER() 按分类排序取 Top 1
直接用 GROUP BY + MAX(sales) 只能拿到最高销售额数值，拿不到对应订单的其他字段（比如订单号、客户名、时间）。真正要“查出那一笔订单的完整详情”，必须保留原始行粒度，靠窗口函数排序后筛选。
核心思路：对每类数据按销售额降序编号，取编号为 1 的行。
-
ROW_NUMBER() OVER (PARTITION BY category ORDER BY sales DESC)是最常用写法，保证每类内唯一编号，即使销售额相同也能强制分出先后 - 如果同一分类下存在多笔相同最高销售额，且你希望全部返回，改用
RANK()或DENSE_RANK()；但注意它们会并列编号（比如两个第一，下一个就是第三），后续过滤条件得写rank - MySQL 8.0+、PostgreSQL、SQL Server、Oracle 都支持；SQLite 3.25+ 也支持，但旧版不支持窗口函数，得换方案
MySQL 5.7 或更老版本怎么绕过窗口函数？
没有 ROW_NUMBER() 就没法优雅地“分组取 Top N”，只能靠关联子查询或自连接，性能差、写法绕，还容易出错。
Monitored Ralph Loop
下载
一款AI工具，主要用于生成可直接复制粘贴的 Bash 脚本，用于 Ralph Wiggum/AI 代理循环（Codex、Claude Code、OpenCode、Goose）。适用于“拉尔夫循环”“Ralph Wiggum 循环”或 AI 循环请求，依据 PROMPT.md、AGENTS.md、SPECS、IMPLEMENTATION_PLAN.md 进行计划/构建，包含计划与构建模式、背压、沙箱及完成条件，适合需要提升相关任务效率的用户。
- 常见错误写法：
SELECT * FROM orders WHERE sales = (SELECT MAX(sales) FROM orders o2 WHERE o2.category = orders.category)—— 看似合理，但若同一分类有多个订单并列最高，会全部返回；而且无法处理 NULL 或重复值导致的意外结果 - 稳妥做法是加一层唯一性保障：先用
GROUP BY category找出每个分类的MAX(sales)和对应最小/最大order_id（假设order_id唯一），再和原表JOIN回去 - 示例片段：
SELECT o.* FROM orders o<br>INNER JOIN (<br> SELECT category, MAX(sales) AS max_sales, MIN(order_id) AS min_oid<br> FROM orders<br> GROUP BY category<br>) t ON o.category = t.category AND o.sales = t.max_sales AND o.order_id = t.min_oid
ORDER BY 里字段顺序影响结果稳定性
窗口函数排序时，如果只写 ORDER BY sales DESC，当同分类内有多笔相同 sales 时，数据库可能每次返回不同行——因为没指定第二排序键，执行计划无确定性。
- 务必补一个能打破平局的字段，比如
order_id、created_at，推荐用主键：ORDER BY sales DESC, order_id ASC - 不要依赖
ORDER BY sales DESC后默认按物理存储顺序返回，那不是标准行为，不同引擎表现不一致 - 如果业务上允许任意一笔并列最高，也要显式写出
ORDER BY sales DESC, order_id，否则测试环境和生产环境可能返回不同记录
性能关键点：分类字段和销售额字段要有联合索引
窗口函数本身不走索引，但 PARTITION BY category ORDER BY sales DESC 这个模式，数据库优化器在多数情况下会尝试利用索引加速分区内的排序。
- 建索引优先级：
CREATE INDEX idx_cat_sales ON orders(category, sales DESC, order_id)—— 把category放最前，sales次之，再加一个用于去重的字段（如order_id） - 避免只建单列
sales索引，它对分组内排序几乎无帮助 - 数据量大时，没索引可能导致全表扫描 + 内存排序，延迟明显上升；加了索引后执行计划里应看到
Using index
窗口函数写法看着简洁，但排序键选不对、索引没跟上，或者低估了老版本兼容性问题，很容易查出错数据或慢得没法上线。尤其要注意并列值场景下的确定性，这不是“理论上可行”就行，而是线上必须稳。
