Cassandra中使用带二级索引的计数器变量是否会降低性能？

二级索引对计数器表的性能影响 #

在计数器表上使用二级索引一定会造成显著性能下降，生产环境完全不推荐这么做，核心原因有三点：

• Cassandra的二级索引是节点本地索引，不是全局分布式索引。写入时除了要更新计数器本身，还要额外维护本地索引的写入；而计数器列本身的写入逻辑就比普通列重——需要通过Quorum级别读改写保证计数准确性，避免多节点更新冲突导致计数漂移，叠加索引维护开销后写放大会放大3-10倍，高并发到访上报场景下很容易出现写超时、计数延迟的问题。
• 走二级索引查询的逻辑是跨节点scatter-gather，需要向集群所有节点发请求拉取结果再聚合，数据量上来之后读延迟完全不可控，根本满足不了统计系统大屏、实时展示的低延迟要求。
• 计数器值是持续高频更新的，二级索引会跟着高频更新，产生大量墓碑数据，大幅拖慢集群Compaction速度，严重时会影响整个集群的稳定性。这也是官方文档明确建议计数器表尽量减少索引的核心原因。

两种可选方案对比 #

首先先纠正你给出的示例里的两个基础错误：

1. Counter类型列不支持用INSERT语句直接赋值初始化，只能通过UPDATE 表名 SET nb = nb + 增量 WHERE 主键条件的方式做增量更新，直接插入固定值会直接报错。
2. 你给出的第二套方案的插入语句存在表名、字段值不匹配，以及event_id类型不匹配的问题（定义为text类型却插入数字值）。

回到两个方案的优劣对比：

• 方案1：单表+二级索引：性能最差，除了上面说的写入、读取性能问题，还会引入额外的集群稳定性风险，直接排除。
• 方案2：每个展位单独建表：虽然避开了二级索引的性能问题，但缺陷非常明显：如果展会展位数量多（几十上百个是很常见的情况），要创建大量结构完全一致的窄表，会大幅提升集群元数据管理的开销，schema同步、节点重启的速度都会明显变慢；如果需要做活动维度的全展位聚合统计，还要跨几十上百张表做查询聚合，开发和运维成本都极高，不是最优选择。

最优设计方案 #

你最初给出的第一版建表语句其实就是最适配这个场景的方案，完全不需要加二级索引：

CREATE TABLE event (
    event_id text,
    stand text,
    nb counter,
    PRIMARY KEY(event_id, stand)
)

这个结构里event_id是分区键，同一个活动的所有展位计数数据都存在同一个分区中，stand是聚类键，完美匹配展位统计场景的两个核心查询路径：

• 上报展位到访时：直接指定event_id和stand，对nb做+1增量更新，直接路由到对应分区写入，无额外索引开销，写入性能最高。
• 查询活动下单个展位计数/全展位计数时：要么直接指定分区键+聚类键查单条数据，要么直接扫描单个分区拿到所有展位的计数，一次请求就能返回结果，读延迟稳定在毫秒级。

如果你有额外的查询需求，比如不指定活动ID查询某个展位的历史累计到访量，不要在主表上加二级索引，单独建一张按展位做分区键的计数器表，上报到访时异步双写增量即可，完全不会影响核心链路的性能。

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