uv统计必须依赖visitor_id或user_id等唯一标识字段，不可用ip或ua；需明确时间窗口与去重逻辑，建议预计算并建立联合索引优化性能，同时确保上报链路完整。
用 GROUP BY 统计短链接点击总量和 UV
直接对 click_log 表按短链 ID 分组，就能拿到每个链接的总点击数（PV）和独立访客数（UV）。关键不是“怎么查”，而是“数据是否支持准确统计 UV”——UV 必须依赖能标识唯一用户的信息，比如 user_id 或加密后的 device_fingerprint，不能只靠 IP 或 UA。
常见错误是直接用 COUNT(*) 当 PV、COUNT(DISTINCT ip) 当 UV：IP 会因 NAT、代理、WiFi 共享而严重高估；UA 极易伪造或重复。真正可用的字段通常是业务侧埋入的 visitor_id（前端生成并持久化在 localStorage 的 UUID）或后端下发的 session_id（带过期时间且绑定设备）。
SELECT short_code, COUNT(*) AS pv, COUNT(DISTINCT visitor_id) AS uv FROM click_log GROUP BY short_code;- 如果表里没有
visitor_id，但有user_id（登录态用户），可改用COUNT(DISTINCT user_id)，但注意未登录用户会被漏掉 - 若只有
ip和ua，建议先加字段再补数据，硬统计只会误导运营决策
如何处理点击时间窗口与去重逻辑
同一个用户短时间内反复点击同一短链，是否算多次 PV？是否算多次 UV？业务定义必须前置。技术上默认按原始日志行计 PV，UV 则依赖去重粒度。
例如：要求“同一用户 24 小时内对同一短链多次点击只计 1 次 UV”，就不能只写 COUNT(DISTINCT visitor_id)，得先过滤或标记有效点击：
- 加时间条件：
WHERE click_time >= NOW() - INTERVAL '1 day'，再分组统计 - 用窗口函数去重（PostgreSQL/MySQL 8.0+）：
ROW_NUMBER() OVER (PARTITION BY short_code, visitor_id ORDER BY click_time DESC)，取每组第一条 - 更稳妥的做法是在写入日志时就做“单日首次点击标记”，避免每次查询都计算
MySQL vs PostgreSQL 在 COUNT(DISTINCT) 上的性能差异
COUNT(DISTINCT x) 在大数据量下都是性能瓶颈，但表现不同：MySQL 5.7 默认使用临时表 + 文件排序，内存不足时会落盘，慢得明显；PostgreSQL 使用哈希聚合，对 visitor_id 这类字符串字段更敏感，若长度超 1024 字节可能退化为排序聚合。
实操建议：
- 给
short_code和visitor_id建联合索引：INDEX(short_code, visitor_id)，能让部分引擎跳过全表扫描 - 数据量超千万时，优先考虑预计算：用定时任务把每日 UV/PV 写入
short_link_daily_stats表，查时直接SELECT SUM(pv), SUM(uv) - 不要在
WHERE条件里对visitor_id用函数（如LOWER(visitor_id)），会失效索引
漏统计的典型场景：重定向中间页没打点
短链服务通常走「短链 → 中间页（含 JS SDK）→ 目标页」流程。如果中间页没触发点击上报，或者 SDK 加载失败、被广告屏蔽插件拦截，click_log 表就完全收不到记录——此时统计结果偏低，但 SQL 本身没错。
排查方法：
- 对比 Nginx 访问日志中
/s/abc123的请求量和click_log中short_code = 'abc123'的条数，差值过大说明上报丢失 - 检查中间页是否包含
sendBeacon()或降级的img.src打点方式，确保无 JS 执行环境也能上报 - 短链跳转若用 HTTP 302，需确认后端是否在重定向前已写入日志，否则用户跳走后写入失败
字段设计、上报链路、SQL 写法三者缺一不可。最容易被忽略的是：UV 定义不一致导致多端数据对不上——App 用 device_id，H5 用 fingerprint，后台又按 user_id 统计，最后谁信谁的数。
