PARTITION BY必须配合窗口函数使用，单独写会报错；它是ROW_NUMBER()等窗口函数的子句，用于按指定字段分组并重置编号，需与ORDER BY配合确保排序稳定，且分组字段建议建立复合索引以提升性能。
PARTITION BY 必须配合窗口函数使用，单独写会报错
直接在 SELECT 里写 PARTITION BY 是无效语法。它只是窗口函数的子句，必须依附于 ROW_NUMBER()、RANK() 或 NTILE() 等函数。常见错误是写成：SELECT *, PARTITION BY customer_id ORDER BY order_date —— 这会触发 ERROR: syntax error at or near "PARTITION"。
正确姿势是把 PARTITION BY 放进括号里，作为窗口函数的参数：
SELECT *,
ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY order_date) AS rn
FROM orders;
-
PARTITION BY customer_id表示按客户分组，每组内独立编号 -
ORDER BY order_date决定组内编号顺序（不加这个，编号是未定义的） - 窗口函数不改变行数，结果集仍为原始行数，只是多了一列编号
按客户+年份分组编号，避免跨年混淆
如果订单时间跨度大，只按 customer_id 分组会导致老客户所有订单挤在一个序列里。实际业务中常需“每个客户每年独立编号”，这时要把年份也纳入 PARTITION BY：
SELECT *,
ROW_NUMBER() OVER (
PARTITION BY customer_id, EXTRACT(YEAR FROM order_date)
ORDER BY order_date
) AS yearly_seq
FROM orders;
-
EXTRACT(YEAR FROM order_date)在 PostgreSQL / Oracle 中可用；MySQL 用YEAR(order_date)；SQL Server 用DATEPART(YEAR, order_date) - 注意：不同数据库对日期函数支持差异大，别直接复制粘贴，先查文档确认函数名
- 如果字段含时分秒，
ORDER BY order_date可能产生相同时间戳，导致编号顺序不稳定（尤其并发插入场景），建议补上主键如ORDER BY order_date, order_id
ROW_NUMBER() vs RANK() vs DENSE_RANK()：选错会影响业务逻辑
三者都支持 PARTITION BY，但处理并列的方式完全不同：
-
ROW_NUMBER()：严格递增，即使值相同也给不同编号（1,2,3…） -
RANK()：跳号并列（值相同时同号，下一名次跳过，如 1,1,3） -
DENSE_RANK()：连续并列（1,1,2）
例如客户 A 有 3 笔同天订单：
用 ROW_NUMBER() 得到 1/2/3；用 RANK() 也是 1/1/1（因为并列第一），但下一笔不同天的订单会变成第 4 名；而 DENSE_RANK() 下一笔是第 2 名。业务上“第几单”通常要严格序号，所以优先选 ROW_NUMBER()。
性能隐患：PARTITION BY 字段没索引，大表查询会变慢
PARTITION BY 本身不建索引，但窗口函数执行时需要按分区字段排序或分组，若 customer_id 没索引，数据库可能触发全表扫描 + 外部排序，千万级订单表可能卡住。
- 检查执行计划：PostgreSQL 用
EXPLAIN ANALYZE，看是否有Sort节点和Buffers高读取 - 加复合索引可显著提速：
CREATE INDEX idx_orders_cid_odate ON orders(customer_id, order_date); - 注意：索引字段顺序必须和
PARTITION BY + ORDER BY一致，否则优化器可能不走索引
真正难的不是写对语法，而是想清楚“按什么分”和“在什么粒度上编号”——这两个问题错一个，后续所有分析都会偏移。
