Cassandra的数据模型围绕主键设计，只有分区键和聚类键上的查询才是高效的。一旦需要按非主键列查询，开发者通常会在物化视图和二级索引之间做选择。这两个特性看起来都能解决问题，但内部机制完全不同，选错了往往在数据量上来之后才发现性能崩塌。理解它们各自的实现原理，是做出正确决策的前提。
二级索引的底层原理与性能陷阱
二级索引（Secondary Index）在Cassandra中并不是像MySQL那样维护一棵全局B+树。它本质上是一张隐藏的本地索引表，表的主键是索引列的值，而值则是 base 表的分区键。每个节点只索引自己拥有的那部分数据，这一点决定了它的所有优缺点。
当你执行一个带二级索引条件的查询时，Cassandra并不知道数据在哪个节点上，只能把查询广播到该表的所有副本所在的节点，每个节点在本地查索引表，再把结果汇总返回。这就是所谓的scatter-gather模式。假设集群有30个节点，即便数据只集中在3个节点上，协调者也要向所有持有该token范围副本的节点发起请求，延迟由最慢的节点决定。
-- 创建二级索引
CREATE TABLE users (
user_id uuid PRIMARY KEY,
email text,
city text,
age int
);
CREATE INDEX ON users (email);
-- 查询会触发全集群范围的scatter-gather
SELECT * FROM users WHERE email = 'test@ipipp.com';二级索引的写入路径很轻量：base 表写入的同时，本地同步更新索引条目，没有跨节点协调开销。这也是它的核心优势——对写性能几乎无影响，且天然保持与base表的一致性，因为索引更新和数据写入发生在同一个节点、同一个写入路径中。
但缺点同样明显。它适合的场景非常有限：高基数码不适合（比如email、uuid这类几乎不重复的值，等值查询等于扫描几乎所有分区）；低基数但分布均匀的列相对合适（比如状态列、布尔标记）；另外它对分区键的等值查询组合比较友好，例如WHERE tenant_id = X AND status = Y这样先限定分区再叠加索引条件，查询会被限制在少数节点上，性能可控。
物化视图的读写路径分析
物化视图（Materialized View）是Cassandra 3.0引入的特性，它在逻辑上是一张按新主键组织的真实表。你按user_id查询用户表，同时又想按city查询，就可以为city建一个物化视图，视图的主键以city开头。查询视图时走的就是普通的主键查询路径，精确定位到具体节点和分区，性能与查主表无异。
-- 基于主表创建物化视图
CREATE MATERIALIZED VIEW users_by_city AS
SELECT user_id, email, age, city
FROM users
WHERE city IS NOT NULL AND user_id IS NOT NULL
PRIMARY KEY (city, user_id);注意视图的主键必须包含base表的全部主键列，这是为了保证每一行在视图中唯一。查询时把视图当成一张普通表即可：
-- 精确的分区级查询，只命中少量节点 SELECT * FROM users_by_city WHERE city = 'Beijing';
代价在写入端。每次写base表，Cassandra都要额外执行视图的写入，而且是异步的。如果更新语句没有覆盖视图主键涉及的旧值，数据库需要先读旧记录才能删除旧的视图行、插入新的视图行，这就是著名的读前开销（read-before-write）。写一张表变成可能两读三写，写放大非常可观。官方文档因此明确建议：更新操作应尽量提供完整的主键上下文，避免触发读前逻辑。
更严重的问题是一致性。视图写入是异步批处理的，理论上base表和视图之间可能出现短暂不一致，极端故障场景下（比如节点在批处理中途宕机）甚至需要执行修复才能对齐。正因如此，Cassandra 4.0一度考虑移除物化视图特性，最终保留但标注为使用需谨慎。如果你对一致性要求苛刻，社区普遍的替代方案是应用层双写：在应用代码里同时写两张表，事务由业务逻辑保证，虽然把复杂度转移给了开发者，但行为完全可控。
两者对比与选型决策
把两个方案放在同一张表里对比会更直观：
| 维度 | 二级索引 | 物化视图 |
|---|---|---|
| 存储形式 | 隐藏的本地索引表 | 真实的物化表 |
| 查询路径 | scatter-gather，广播所有节点 | 主键精确路由 |
| 写性能 | 几乎无影响 | 明显写放大，可能触发读前开销 |
| 读性能 | 随集群规模和数据量恶化 | 接近主表查询 |
| 一致性 | 与base表强同步 | 最终一致，故障后可能需修复 |
| 适用基数 | 低到中等基数 | 任意基数 |
实际的选型可以按这样的思路来。首先问自己：这个查询是不是真的高频且关键？如果只是偶尔的运营后台查询，直接用Spark或允许超时的扫描任务，不必引入索引结构。如果查询高频，再看查询模式：能不能在分区键内做过滤？如果查询条件里已经带上了分区键等值条件，二级索引配合使用往往是最省事的方案，写路径零负担，读路径也被限制在单分区内。
如果查询列要单独作为新的访问入口，数据量又大，物化视图或应用层双写才是正解。这时评估两点：一是写入吞吐能否承受翻倍甚至更高的写放大，二是一致性要求是否允许最终一致。很多团队在实践中更倾向应用层双写，因为物化视图的修复运维成本高，而双写的逻辑可以用一个封装好的DAO层统一处理，出问题时的排查路径也更清晰。
最后提醒一点，无论选哪种方案，都不要忘记Cassandra建模的第一原则：围绕查询设计表。物化视图和二级索引都是主键设计不足的补救措施，而不是常规手段。能在建模阶段通过反规范化多写一张表解决的问题，就不要留给运行时的索引机制，这也是Cassandra与关系型数据库在设计哲学上最根本的差异。
Cassandra materialized viewsecondary index二级索引修改时间：2026-09-07 20:28:48