不能直接用 COUNT(DISTINCT)/COUNT(DISTINCT)，因为分母可能为0，MySQL/SQL Server整数除法会截断小数导致结果恒为0或1，且无法区分真实0转化与数据缺失；正确做法是用CASE WHEN+NULLIF+100.0确保浮点运算、防除零，并保证分子分母基于同一用户集合和时间粒度。
为什么不能直接用 COUNT(DISTINCT) 除以 COUNT(DISTINCT)
因为分母可能为 0，且整数除法在 MySQL/SQL Server 中会截断小数——COUNT(DISTINCT user_id) / COUNT(DISTINCT user_id) 在 MySQL 里结果恒为 1 或 0，不是小数。更危险的是，如果某天没下单，分母非零但分子为 0，除法虽不报错，但结果是 0 而非 NULL，掩盖了数据缺失问题。
CASE WHEN + COUNT(DISTINCT) 的正确写法
核心是让分子分母都基于同一用户集合、同一时间粒度，并显式控制空值和类型转换：
- 分母必须是「漏斗起点的去重用户数」，比如
COUNT(DISTINCT CASE WHEN event_type = 'page_view' THEN user_id END) - 分子是「在起点用户中，完成后续动作的去重用户数」，比如
COUNT(DISTINCT CASE WHEN event_type = 'purchase' THEN user_id END) - 必须乘
100.0（不是 100）触发浮点运算，避免整数除法截断 - 用
NULLIF(..., 0)包裹分母，防止除零；SQLite 不支持NULLIF，得改用IIF(denom = 0, NULL, ...)
示例（按天统计访问→支付转化率）：
SELECT
DATE(event_time) AS dt,
COUNT(DISTINCT CASE WHEN event_type = 'page_view' THEN user_id END) AS uv_view,
COUNT(DISTINCT CASE WHEN event_type = 'purchase' THEN user_id END) AS uv_pay,
ROUND(
COUNT(DISTINCT CASE WHEN event_type = 'purchase' THEN user_id END) * 100.0 /
NULLIF(COUNT(DISTINCT CASE WHEN event_type = 'page_view' THEN user_id END), 0),
2
) AS cvr
FROM events
WHERE event_time >= '2026-05-01'
GROUP BY DATE(event_time);
容易被忽略的去重逻辑陷阱
转化率不是“所有下单用户 / 所有访问用户”，而是“在访问过的用户里，有多少人后来下单”。如果只分别算两个 COUNT(DISTINCT user_id) 再相除，就忽略了用户行为的时间先后与归属关系：
- 用户 A 在 5 月 1 日访问、5 月 3 日下单 → 该下单不应计入 5 月 1 日的转化分母
- 用户 B 在 5 月 1 日既访问又下单 → 必须确保两次事件能关联到同一天，否则分子分母跨天对不齐
- 若需“访问后 N 天内下单”，分母仍取访问日用户，但分子得加时间窗口过滤：
CASE WHEN event_type = 'purchase' AND event_time BETWEEN visit_time AND DATE_ADD(visit_time, INTERVAL 7 DAY) THEN user_id END
这时候单靠 COUNT(DISTINCT) + CASE 不够，必须先用 JOIN 或 EXISTS 锁定“先有访问、后有下单”的用户对。
当漏斗多于两步时，别堆 CASE
三步以上（如 view → cart → purchase）还硬塞进一个 COUNT(DISTINCT CASE...) 表达式，可读性崩坏，也难以调试各环节数值。此时应：
- 用 CTE 分层定义每步用户集合，例如
WITH views AS (SELECT DISTINCT user_id, DATE(event_time) AS dt FROM events WHERE event_type = 'page_view') - 再 LEFT JOIN 各环节，确保用户路径可追溯，而不是靠 CASE 猜测归属
- 各环节的
COUNT(DISTINCT user_id)单独验证，比嵌套 CASE 更易定位哪一步数据异常
复杂漏斗真正的难点从来不是语法，而是明确“谁算进分母”——这个判断一旦错，后面所有数字都是幻觉。
