row_number()必须配合partition by和order by才能实现按客户分组排序；单独使用仅对全表连续编号，无法自动按客户归类。
ROW_NUMBER() 必须配合 PARTITION BY 和 ORDER BY 才能按客户分组排序
单独写 ROW_NUMBER() 不会自动按客户归类，它默认对全表连续编号。要“每位客户最近的收货地址”，核心是先按 customer_id 分组（PARTITION BY customer_id），再在每组内按时间倒序排（ORDER BY updated_at DESC）。漏掉 PARTITION BY 就变成全表排第一，不是每个客户各自的第一。
常见错误现象：ROW_NUMBER() 结果里多个客户共享同一个“1”，或者只返回一条记录——大概率是忘了 PARTITION BY，或 WHERE 写在了窗口函数外却没用子查询/CTE 包裹。
- 务必把
ROW_NUMBER()放在子查询或 CTE 中，再在外层WHERE rn = 1 - 如果
updated_at有重复值，建议追加id DESC等确定性排序，避免结果不稳定 - MySQL 8.0+、PostgreSQL、SQL Server、Oracle 都支持；SQLite 3.25+ 也支持，但旧版不支持
用 CTE 写最清晰，避免嵌套过深
比起多层子查询，用 WITH 定义 CTE 更易读、调试也方便。CTE 名字直接体现意图，比如 ranked_addresses，一眼知道这是带序号的地址列表。
WITH ranked_addresses AS (
SELECT
customer_id,
address_line1,
city,
updated_at,
ROW_NUMBER() OVER (
PARTITION BY customer_id
ORDER BY updated_at DESC, id DESC
) AS rn
FROM shipping_address
)
SELECT customer_id, address_line1, city, updated_at
FROM ranked_addresses
WHERE rn = 1;
注意：这里 ORDER BY updated_at DESC, id DESC 是为了在时间相同时取最新插入的那条（假设 id 自增）；如果业务上允许任意一条，可只留 updated_at DESC。
性能关键：customer_id + updated_at 要建联合索引
ROW_NUMBER() 本身不走索引，但 PARTITION BY 和 ORDER BY 的字段直接影响排序开销。没索引时，数据库得对整张表排序，地址表一旦超 10 万行，查询明显变慢。
- 推荐索引：
CREATE INDEX idx_cust_updated ON shipping_address (customer_id, updated_at DESC); - PostgreSQL 支持
DESC显式索引；MySQL 8.0+ 也支持，但老版本会忽略DESC，实际建的是升序索引，仍可用但效率略低 - 如果表常按
customer_id查询，这个联合索引还能顺便加速其他关联查询
遇到 NULL updated_at 怎么办？
如果 updated_at 允许为空，ORDER BY updated_at DESC 会让 NULL 排在最前面（多数数据库默认行为），导致空时间戳被误判为“最新”。这不是 bug，是标准 SQL 行为。
- 安全做法：显式控制 NULL 位置，例如
ORDER BY updated_at DESC NULLS LAST（PostgreSQL、Oracle、SQL Server 支持） - 兼容写法（所有数据库都行）：
ORDER BY CASE WHEN updated_at IS NULL THEN 0 ELSE 1 END DESC, updated_at DESC - 更彻底的方案：建表时设
updated_at为NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP，从源头避免 NULL
ROW_NUMBER() 这步看似简单，但分区逻辑错一位、索引缺一个字段、NULL 处理少一行条件，结果就可能漏掉几十个客户的最新地址——尤其当数据来自不同系统拼接，时间字段语义不统一时。
