直接按row_number()序号join会错配，因进出记录被分别分区编号，同用户进/出序号各自从1起算，导致a1-b1无法对齐；应共用基于业务字段的稳定桶标识（如date+user_id%4）或统一全局序号除法生成桶id。
为什么直接用 ROW_NUMBER() 分桶后 JOIN 会错配
因为 ROW_NUMBER() 是按单表排序独立编号的，两张表各自分桶时编号逻辑不一致，即使都按时间排序，只要数据分布不均或存在并列值，桶内记录数和顺序就无法对齐。常见现象是：本该配对的 A1–B1 变成 A1–B2，或者某条 B 记录被跳过。
真正可靠的做法是让双方共用同一套分桶依据——不是靠行号，而是靠可复现、可比较的「桶标识」。
- 优先用业务字段构造稳定分组键，比如
DATE(created_at)+user_id % 4，而非依赖排序位置 - 若必须按顺序分桶（如“每 3 条 A 配 1 条 B”），需先用
ROW_NUMBER()算出全局序号，再统一除法取整生成桶 ID：(ROW_NUMBER() OVER (ORDER BY id) - 1) / 3 - 注意：PostgreSQL 和 SQL Server 支持整数除法自动截断，MySQL 需用
FLOOR((rn - 1) / 3)
如何用 NTILE() 实现“尽量均匀分 N 组”但避免隐式排序陷阱
NTILE(4) 看似方便，但它会在内部强制按 ORDER BY 排序后再切分，而这个排序若没显式指定，不同数据库行为不一（有的按主键，有的未定义）。更危险的是：当总行数不能被 4 整除时，前几组会多 1 行，导致各桶大小不等——这在需要严格 1:1 匹配时直接崩盘。
- 永远显式写
ORDER BY，且字段必须有确定性（避免用random()或无索引字段） - 若目标是“每桶固定大小”，别用
NTILE()，改用(ROW_NUMBER() OVER (...) - 1) / bucket_size - 验证分桶结果：加
COUNT(*) GROUP BY bucket_id查看各桶行数是否符合预期
JOIN 时怎么让 A 表和 B 表落到同一个桶里
关键不是分别算桶，而是让两表基于相同逻辑生成桶 ID，再用这个 ID 关联。例如要实现“按创建日期天粒度分桶，每天最多匹配 5 条 A 和 5 条 B”：
SELECT a.*, b.*
FROM (
SELECT *,
DATE(created_at) AS day_key,
(ROW_NUMBER() OVER (PARTITION BY DATE(created_at) ORDER BY id) - 1) / 5 AS bucket_seq
FROM orders a
) a
JOIN (
SELECT *,
DATE(created_at) AS day_key,
(ROW_NUMBER() OVER (PARTITION BY DATE(created_at) ORDER BY id) - 1) / 5 AS bucket_seq
FROM refunds b
) b
ON a.day_key = b.day_key AND a.bucket_seq = b.bucket_seq
- 必须保证两个子查询中
PARTITION BY和ORDER BY完全一致，否则同一天内编号错位 - 如果某天 A 有 12 条、B 只有 3 条，则只有前 3 条 B 能匹配（
bucket_seq为 0 的那组），其余 A 桶无匹配项——这是预期行为，不是 bug - 想控制匹配优先级？把
ORDER BY换成ORDER BY status DESC, created_at即可让已审核订单优先进桶
性能差、查半天不出结果？检查这几个地方
窗口函数本身不慢，慢在没走索引或重复计算。最常被忽略的是：子查询里写了窗口函数，外层又对结果做复杂过滤，导致数据库无法下推条件。
- 把过滤条件尽量提到窗口函数外层子查询之前，比如先
WHERE status = 'paid'再开窗 -
ORDER BY字段必须有索引，特别是多字段排序时，复合索引顺序要和ORDER BY严格一致 - 避免在
ON条件里实时算桶 ID（如(ROW_NUMBER()...) / 5），必须提前算好作为字段参与 JOIN - 大表分桶 JOIN 前，先用
EXPLAIN看是否走了 Hash Join；如果看到 Nested Loop，说明桶 ID 列没索引或类型不匹配（如一边是INT一边是BIGINT）
分桶匹配的本质是人为制造关联键，它不解决数据语义上的合理性，只解决“怎么可控地拉平数量差异”。桶 ID 一旦生成，就和原始业务逻辑脱钩了——这点容易被忽略，但决定了后续排查问题的方向。
