Cassandra的数据模型围绕主键设计，只有按照分区键和聚簇列组织的查询才能获得最佳性能。但真实业务中，我们经常需要按非主键列查询数据，比如按用户邮箱查用户、按订单状态查订单。这时候materialized view（物化视图）和secondary index（二级索引）是两个常见选项，它们看起来功能相似，底层实现却完全不同，选错了很容易把集群性能拖垮。
一、底层实现机制的差异
先看物化视图。物化视图在Cassandra中本质上是一张独立的表，只不过这张表的数据由Cassandra自动维护，不需要应用层手动写入。当你往基表写入数据时，协调节点会同时向基表和所有物化视图发起写请求，视图表以你指定的列作为新的主键存储数据。也就是说，物化视图的每一份数据都是完整落盘的，查询它和查询一张普通表没有任何区别。
而二级索引完全不同。它并不是把数据复制一份，而是为被索引列在本地节点上构建一张隐藏的索引表，索引表的结构是"索引列值到主键值"的映射。执行查询时，协调节点需要把请求广播到整个集群的所有副本节点，每个节点在本地查索引表拿到主键，再回表读取完整数据，最后汇总返回。这个广播加回表的过程就是二级索引性能问题的根源。
可以简单理解为：物化视图是空间换时间，用双倍存储和写入放大换取查询时的高效；二级索引是计算换空间，存储开销小，但查询时要做更多工作。
二、建表语句与查询示例对比
下面用一个订单表的例子来演示两种方案的用法。先创建基表：
CREATE TABLE orders (
order_id uuid,
user_id uuid,
order_status text,
amount decimal,
created_at timestamp,
PRIMARY KEY (order_id)
);
-- 方式一：创建物化视图，按状态查询
CREATE MATERIALIZED VIEW orders_by_status AS
SELECT order_id, user_id, amount, created_at
FROM orders
WHERE order_id IS NOT NULL AND order_status IS NOT NULL
PRIMARY KEY (order_status, order_id);
-- 方式二：创建二级索引
CREATE INDEX idx_orders_status ON orders (order_status);
注意物化视图的几个细节：视图中必须包含基表的全部主键列，并且要在WHERE子句中用IS NOT NULL声明这些列不允许为空，否则建表会报错。视图的新主键由order_status和order_id组成，这意味着查询时必须带上order_status作为分区键。
两者的查询写法也有区别：
-- 查询物化视图，等价于普通表的主键查询 SELECT * FROM orders_by_status WHERE order_status = 'PAID'; -- 使用二级索引查询基表 SELECT * FROM orders WHERE order_status = 'PAID';
前者走的是标准的分区定位，只命中持有该分区数据的节点；后者则要扫描全部节点的本地索引。当集群有几十个节点、而PAID状态占了大半数据时，二级索引的代价会非常惊人。
三、性能与一致性方面的实际影响
写入性能方面，物化视图会带来明显的写入放大。每多建一个视图，每次写入就多一次（甚至更多）远程写操作，而且视图写入和基表写入之间存在一个轻量级事务来保证一致性，写入延迟会显著增加。官方建议每张表的物化视图数量要严格控制，通常不超过两三个。
二级索引对写入的影响小得多，因为索引和数据写在同一个节点本地完成，没有额外的跨节点开销。这也是很多人偏爱二级索引的原因——建索引很便宜，删掉也很容易。但代价转嫁到了读路径上，尤其是高基数列（比如email、uuid这类几乎不重复的列），广播到全集群后每个节点可能只返回寥寥几条结果，网络往返和合并成本完全不成比例。
一致性方面还有一个重要坑点：物化视图在极端情况下（节点故障期间部分写入失败）可能出现视图与基表短暂不一致，虽然Cassandra 4.0之后做了修复改进，但使用时仍要有心理预期。二级索引则是最终一致的本地索引，如果本地索引写入失败会自动重建，一般不会丢数据。
四、如何选择：场景决定方案
综合来看，两条简单的判断标准基本覆盖大多数场景。第一，被查询的列基数如何？如果列的取值很少（比如状态、类型、性别），用二级索引可以接受；如果基数很高且某个值对应大量数据，物化视图更合适。第二，读写比例如何？写多读少且查询频繁的列，物化视图带来的稳定读性能值得付出写入代价；很少查询的列就别建索引了，白白浪费资源。
还有几个实践建议值得记住。物化视图在4.0之前的版本中曾被标记为实验特性，生产使用前务必确认你的版本对它的支持状态，社区对这个特性的成熟度一直有争议。如果一个查询模式足够重要且固定，更稳妥的做法往往是不用视图，而是在应用层同时写两张表，自己控制写入顺序和失败补偿逻辑，这也是很多大厂在Cassandra上的标准做法。
另外，无论哪种方案，都要警惕ALLOW FILTERING。看到查询计划里出现全表扫描的告警时，说明数据模型设计已经和查询需求脱节，这时候应该回头重新设计主键，而不是寄希望于索引来补救。Cassandra的核心哲学始终是：查询决定表结构，先把查询模式想清楚，索引只是补充手段，不是万能药。
Cassandra materialized viewsecondary index物化视图修改时间：2026-09-13 01:30:33