Cassandra 文档指出，
在这些情况下不要使用索引：
- 在高基数列上，因为您随后会为少量结果查询大量记录。请参阅下面的使用高基数列索引的问题。
它继续，
如果您在具有许多不同值的高基数列上创建索引，则字段之间的查询将导致为极少的结果进行多次搜索。在包含 10 亿首歌曲的表格中，按作者（每首歌曲通常唯一的值）而不是按艺术家查找歌曲可能会非常低效。手动维护表作为索引的形式而不是使用 Cassandra 内置索引可能会更有效。对于包含唯一数据的列，为了方便起见，有时使用索引在性能方面是很好的，只要对具有索引列的表的查询量适中并且不是在恒定负载下。
但从来没有真正回答过这个问题：为什么它效率低下？我不知道“手动维护表格作为索引的形式”是什么意思。但是它与“......有时为了方便而使用索引在性能方面是很好的，只要查询量适中......”有点矛盾。
这是否只是想告诉我何时何地可以使用 PK？什么是低效？我的理解是，命中索引的查询需要查询集群中的每个¹节点，然后每个节点将在其本地索引中进行查找，然后将结果汇总。这并不一定很昂贵（每个索引查找应该相当便宜），除了我们支付网络延迟，因为我们必须等待该批次中最慢的节点。我在这里错过了什么吗？
但是，如果我有一个包含大量项目的集合——在极少数情况下——需要通过不同但几乎独特的属性来查找……这是一个合适的用途，对吧？
¹每个？IDK，如果复制意味着这可以达到集群的 1/3，复制因子是否为 3？