uuid字段聚合易慢，因text存储致索引膨胀、比较开销大、排序内存不足；须用uuid类型、建b-tree索引、避免隐式转换；count(*)最快，count(distinct id)不必要除非查异常；group by需防前缀分组和null陷阱；mvcc下count结果具快照一致性，非实时强一致。

直接用 COUNT()、DISTINCT 或 GROUP BY 处理 UUID 字段完全可行，但性能和语义陷阱比你想象的多——尤其当表超千万行、UUID 是主键或高频查询字段时。

为什么 UUID 字段聚合容易慢？

UUID 本身是 16 字节二进制值，但很多人误用 text 类型存储（比如存成 'a1b2c3d4-...'::text），这会导致：索引体积翻倍、B-tree 比较开销大、排序阶段内存不足触发磁盘归并。即使用了原生 uuid 类型，若没建索引或 WHERE 条件无法走索引，COUNT(*) 仍要全表扫描。

• 确认字段类型：SELECT column_name, data_type FROM information_schema.columns WHERE table_name = 'your_table' AND column_name = 'id'; —— 必须是 uuid，不是 text 或 varchar
• 检查索引：\d your_table 看主键是否为 uuid 类型的 B-tree；若无，且常按该字段聚合，补一个：CREATE INDEX CONCURRENTLY ON your_table (id);
• 避免隐式转换：写 WHERE id = 'a1b2...' 没问题，但 WHERE id::text LIKE 'a1b2%' 会强制全表转字符串，索引失效

COUNT 和 DISTINCT 在 UUID 字段上的实际表现差异

COUNT(*) 统计行数，最快；COUNT(id) 和 COUNT(DISTINCT id) 都要判空和去重，但 UUID 主键天然非空，所以 COUNT(id) ≈ COUNT(*)；而 COUNT(DISTINCT id) 在无重复前提下仍是全字段扫描+哈希去重，没必要。

• 统计总记录数 → 用 COUNT(*)，它跳过字段检查，走最简路径
• 确认主键无重复 → 不需要 COUNT(DISTINCT id)，除非你怀疑数据异常（此时应查约束，而非靠聚合补救）
• 真要查“不同 UUID 的数量”（比如某关联表里外键引用了多少个唯一实体），且该字段允许 NULL → 显式写 COUNT(DISTINCT id)，但确保 id 列上有索引，否则 PG 可能放弃哈希聚合改用排序聚合，更慢

GROUP BY uuid 字段时的常见错误

对 UUID 字段 GROUP BY 本身没问题，但容易踩两个坑：一是误以为能“按前缀分组”，二是忽略 NULL 值导致结果不全。

• 不能直接 GROUP BY SUBSTRING(id::text, 1, 8) 做粗粒度统计——这会强制全表转字符串、无法用索引，千万级表可能卡死；如真需按生成批次分析，应在插入时额外存 uuid_version 或 created_at，然后按时间分组
• GROUP BY id 后再 HAVING COUNT(*) > 1 查重复？别这么干。UUID 主键重复是数据异常，应靠唯一约束拦截，而不是靠聚合事后发现
• 如果字段允许 NULL，GROUP BY 会把所有 NULL 归为一组；若想排除，加 WHERE id IS NOT NULL，别依赖 HAVING

高并发写入场景下聚合结果不准的隐蔽原因

PG 的 MVCC 机制意味着聚合查询看到的是查询启动时刻的快照。但如果在执行 SELECT COUNT(*) FROM huge_table 的同时，有大量 INSERT/DELETE 正在进行，且事务未提交，COUNT 结果是确定的，但可能和业务感知的“当前总数”有短暂偏差——这不是 bug，是隔离级别保障的一致性。

• 若必须强一致总数（比如财务对账），不要依赖实时 COUNT(*)，改用维护好的物化视图或计数器表 + 原子更新
• UUID 写入热点问题（如 gen_random_uuid()）不影响聚合结果正确性，但会让 COUNT 扫描变慢——因为数据物理分布离散，缓存命中率低，磁盘 I/O 上升
• 对超大表做周期性聚合统计，优先考虑 pg_stat_all_tables.n_tup_ins 这类统计视图估算，比扫全表快几个数量级，误差通常可接受