Cassandra二级索引查询去重问题：GROUP BY警告与方案优化咨询

首先，咱们一步步拆解你遇到的问题，从原理到解决方案逐一说明：

1. 为什么SELECT DISTINCT office FROM report WHERE created_by = ?会报错？ #

Cassandra对DISTINCT的使用有严格限制：当查询带WHERE子句时，DISTINCT只能配合主表的分区键或者静态列使用。你的查询中，created_by是二级索引列，并非主表report的分区键（主表分区键是office），不符合规则，所以报错是预期行为。

2. GROUP BY office的警告是什么意思？能不能忽略？ #

这个警告Aggregation query used without partition key是Cassandra在提醒你：当前查询没有指定主表的分区键，需要跨多个分区扫描数据。

• 能不能忽略？
  如果是测试环境、数据量极小（比如每个用户关联的office数量很少），短期内可以暂时忽略；但如果是生产环境且数据量会持续增长，绝对不能忽略。因为跨分区查询需要协调节点从多个集群节点拉取数据，在内存中完成分组聚合，数据量越大，内存压力、网络延迟都会急剧上升，甚至可能导致协调节点内存溢出（OOM）。

3. Cassandra是怎么处理这类GROUP BY查询的？ #

当你执行SELECT office FROM report WHERE created_by = ? GROUP BY office时，流程是这样的：

1. 先通过二级索引created_by_idx找到所有匹配created_by = ?的行（也就是扫描二级索引表report2中对应created_by的分区）；
2. 把这些行的office字段拉到协调节点；
3. 协调节点在内存中对office进行分组去重，最后返回结果。

整个过程的性能瓶颈在于需要扫描的行数——如果某用户创建过大量报告，协调节点需要处理的数据集会非常大，性能会显著下降。

4. 这个GROUP BY查询和SELECT *比，哪个更好？ #

相比SELECT * FROM report WHERE created_by = ?然后在客户端去重，GROUP BY的查询确实更优：

• 它只返回去重后的office值，减少了网络传输的数据量；
• 把去重的工作从客户端转移到了Cassandra协调节点，减轻了客户端的计算压力。

但本质上，两者都是基于二级索引的跨分区查询，性能上限都不高，数据量增长后都会出现明显的性能问题。

最优解决方案：反范式建模 #

既然你有“查询某用户创建过报告的所有office”这个高频需求，最符合Cassandra设计理念的方式是专门建一张表来存储用户与office的关联关系，完全绕过二级索引和聚合查询：

CREATE TABLE user_offices (
    created_by uuid,
    office uuid,
    PRIMARY KEY (created_by, office)
);

然后在业务逻辑中，每次用户创建报告时，除了写入report表，还执行以下语句写入这张表（避免重复）：

INSERT INTO user_offices (created_by, office) VALUES (?, ?) IF NOT EXISTS;

之后查询用户的所有office时，直接执行：

SELECT office FROM user_offices WHERE created_by = ?;

这个查询完全符合Cassandra的分区键查询规则，没有任何警告，性能极佳，而且天然就是去重后的结果。

内容的提问来源于stack exchange，提问作者Simone