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这类统计视图估算，比扫全表快几个数量级，误差通常可接受
