非等值join关联区间表最稳妥，需确保区间无重叠；若允许多匹配则用lateral或row_number()取首行；group by须含区间标识字段；mysql 5.7需改用cross join+where；等距区间可用递归cte生成。
用非等值 JOIN 关联预定义区间表最稳妥
动态分组区间不能靠 CASE WHEN 硬编码，尤其当区间来自配置表、随业务变化时。核心是把区间抽象成独立表（含 low 和 high 字段），再用非等值 JOIN 让原始数据“落入”对应区间。
常见错误是直接写 ON value BETWEEN r.low AND r.high 却没校验区间是否重叠——一旦 r 表里有 [10,20) 和 [15,25)，一条 value = 17 的记录就会命中两行，后续 COUNT(*) 被重复计算。
- 右表（区间表）必须保证无重叠：入库前用
NOT EXISTS检查，或加唯一约束（如 PostgreSQL 的EXCLUDE USING gist (int4range(low, high) WITH &&)） - 若业务允许多匹配（如按优先级选最高佣金档），改用
LATERAL子查询或ROW_NUMBER() OVER (PARTITION BY t.id ORDER BY r.priority DESC)取首行 -
GROUP BY必须包含区间标识字段（如r.tier_name），不能只写原始值字段 - MySQL 5.7 不支持
ON中的非等值条件，得改写为CROSS JOIN + WHERE
用递归 CTE 构造连续等距区间（适合规则化分段）
当区间是等宽且连续（如每 5 岁一段、每 10 分一段），用 WITH RECURSIVE 生成维度表比手写几十个 WHEN 更安全、易维护。但注意不是所有数据库都支持——SQLite 和 MySQL
关键点在于开闭区间一致性。比如年龄分段 [0,5), [5,10), …，JOIN 条件必须统一用 ON u.age >= d.low AND u.age ，混用 <code>BETWEEN 会漏掉边界值。
- 递归终止条件必须明确，例如
WHERE upper_bound ，否则可能无限循环 - 生成的维度表应带主键或唯一组合（如
(low, high)），避免 JOIN 时笛卡尔爆炸 - 大表关联时，给原始表被匹配字段（如
age）建索引，性能提升明显
用窗口函数 + LAG 动态识别“片”边界（时间类动态切片）
真正动态的区间（如“连续 5 分钟内有数据即为一片”）无法靠静态区间表解决，必须用窗口函数识别断点。本质是先标记“新片开始”，再用累计和生成片 ID。
典型错误是漏写 ROWS UNBOUNDED PRECEDING。PostgreSQL 默认 SUM() OVER (ORDER BY ...) 是 RANGE 模式，相同时间戳的记录会被合并计数，导致片 ID 错乱。
- 先用
LAG(event_time) OVER (ORDER BY event_time)取上一行时间 - 用
CASE WHEN event_time - LAG() > INTERVAL '300' SECOND THEN 1 ELSE 0 END标记断点 -
SUM(断点标记) OVER (ORDER BY event_time ROWS UNBOUNDED PRECEDING)生成片 ID -
event_time字段必须有索引，否则LAG排序成本极高
用 FLOOR + UNIX_TIMESTAMP 实现任意分钟粒度分组
固定时间粒度（如每 7 分钟、每 25 分钟）分组，DATE_FORMAT 会因字符串截断出错，必须用时间戳算术运算。核心是把时间转为秒数、减基准时间、再整除粒度。
容易忽略的是时区和字段类型：UNIX_TIMESTAMP() 对字符串或带毫秒的 DATETIME(3) 返回 NULL，整批数据进空桶；东八区时间需先用 CONVERT_TZ 转 UTC 再算。
- 基准时间建议选早于全量数据的整点时刻（如
'2026-01-01 00:00:00'），避免负数导致FLOOR错位 - 10 分钟分组公式：
FLOOR((UNIX_TIMESTAMP(t) - UNIX_TIMESTAMP('2026-01-01 00:00:00')) / 600) - 还原可读时间用
DATE_ADD('2026-01-01 00:00:00', INTERVAL time_group * 600 SECOND) - 别在
WHERE里对DATE_FORMAT结果过滤，应改用真实时间范围条件
动态区间真正的难点不在语法，而在于“边界定义是否闭环”。时间片要明确定义“间隔多久算断开”，数值区间要确认“左闭右开还是全闭”，配置表要约束“不能重叠也不能留缺口”——这些逻辑漏洞，SQL 写得再漂亮也救不回来。
