基础分群用GROUP BY+聚合函数，需确保SELECT中非聚合字段全在GROUP BY中；动态分位用NTILE或PERCENT_RANK；复杂逻辑宜用CTE分步处理；避免COUNT(DISTINCT)性能瓶颈。
用 GROUP BY + 聚合函数做基础分群
用户分群最直接的方式，就是按某个业务维度（比如注册渠道、地域、年龄段）分组，再统计关键指标。这时候 GROUP BY 是核心，配合 COUNT()、AVG()、SUM() 等聚合函数就能快速产出人群画像。
常见错误是漏写 SELECT 中的非聚合字段——只要用了聚合函数，所有未被聚合的字段都必须出现在 GROUP BY 子句里，否则多数数据库（如 MySQL 8.0+ 严格模式、PostgreSQL）会报错：ERROR: column "xxx" must appear in the GROUP BY clause。
- 想看各渠道的用户数和平均下单金额：
SELECT channel, COUNT(*) AS user_cnt, AVG(order_amount) FROM users u JOIN orders o ON u.user_id = o.user_id GROUP BY channel - 注意：如果
orders表里一个用户有多笔订单，这样会按订单行聚合，不是按用户聚合——需要先去重或用子查询 - 年龄分群别硬写
WHERE age BETWEEN 18 AND 25再查多次，用CASE WHEN一次性分类更高效
用窗口函数做动态分位分群
当需要按行为强度（如消费总额、登录频次）把用户划入 Top 10%、中段、长尾等相对层级时，NTILE() 或 PERCENT_RANK() 比手工算阈值更稳——它自动适配数据分布变化，避免某月大促后阈值失效。
典型陷阱是误用 RANK() 或 ROW_NUMBER()：前者会跳过重复值导致桶不均，后者完全无视数值大小只按顺序排，都不适合“按值分段”场景。
- 按总消费分四档（四分位）：
SELECT user_id, total_amount, NTILE(4) OVER (ORDER BY total_amount) AS quartile FROM (SELECT user_id, SUM(amount) AS total_amount FROM orders GROUP BY user_id) t -
NTILE(4)不保证每组行数完全相等（总数不能被 4 整除时），但比手动算PERCENTILE_CONT阈值更轻量 - 若需精确百分位（如前 5% VIP），优先用
PERCENT_RANK() OVER (ORDER BY total_amount) ，注意它是从 0 开始的归一化值
用 CTE 或临时表组合多维标签
真实分群往往不是单条件，而是“近 30 天活跃且过去一年复购 ≥2 次且客单价 > 200”的组合。硬写在 WHERE 里嵌套深、难维护，用 CTE 分步打标更清晰。
别在每个子查询里重复写时间过滤条件（比如都加 WHERE event_time >= '2024-01-01'），容易漏改、逻辑不一致；统一提到最外层或用参数化视图替代。
- 先筛活跃用户：
WITH active_users AS (SELECT DISTINCT user_id FROM events WHERE event_type = 'login' AND event_time >= CURRENT_DATE - INTERVAL '30 days') - 再关联行为标签：
, purchase_stats AS (SELECT user_id, COUNT(*) AS order_cnt, AVG(amount) AS avg_order FROM orders WHERE order_time >= CURRENT_DATE - INTERVAL '365 days' GROUP BY user_id) - 最后 JOIN 打标：
SELECT a.user_id, CASE WHEN p.order_cnt >= 2 AND p.avg_order > 200 THEN 'high_value' ELSE 'other' END AS segment FROM active_users a LEFT JOIN purchase_stats p USING(user_id)
避免 COUNT(DISTINCT) 在大数据量下拖慢查询
分群分析常要算“各渠道的去重用户数”，但 COUNT(DISTINCT user_id) 在亿级订单表上极易成为性能瓶颈，尤其当 user_id 无索引或分布倾斜时。
MySQL 5.7 和旧版 PostgreSQL 对 COUNT(DISTINCT) 优化有限，而 Hive/Spark SQL 虽支持近似去重（APPROX_COUNT_DISTINCT），但线上分析一般不敢用误差结果。
- 优先走预聚合：每天跑定时任务，把“渠道-日期-去重用户数”存成宽表，查询时直接
SUM(user_cnt) - 实在要实时算，确认
user_id字段有索引；若用的是 ClickHouse，改用uniqCombined(user_id)，性能提升明显 - 别在同一个查询里对多个字段同时
COUNT(DISTINCT)（如渠道去重用户 + 去重设备），某些引擎会退化为多次全表扫描
分群逻辑越复杂，中间状态越要落地成物化视图或临时表——临时拼接的多层子查询看着简洁，出问题时根本没法定位哪一层的数据畸变。
