本文深入探讨了Cassandra中复合主键与`ORDER BY`子句的使用限制，特别是当涉及二级索引时。核心内容阐明了`ORDER BY`仅支持主键中的第一个聚簇列（即复合主键的第二部分），并指出二级索引无法改变这一排序行为。文章通过具体案例和解决方案，指导用户如何根据查询需求重新设计表结构，以满足特定的排序要求。
理解Cassandra的ORDER BY限制
在Cassandra中，数据存储的物理顺序是根据主键定义的。主键由分区键（Partition Key）和聚簇键（Clustering Key）组成。分区键决定了数据在集群中的分布，而聚簇键则决定了在单个分区内数据的排序顺序。ORDER BY子句的排序能力严格依赖于这个预定义的聚簇顺序。
考虑以下表结构：
CREATE TABLE global_product_highlights ( deal_id text, product_id text, highlight_strength double, category_id text, creation_date timestamp, rank int, PRIMARY KEY (deal_id, product_id, highlight_strength) );
在这个表中，deal_id是分区键，(product_id, highlight_strength)是聚簇键。这意味着在deal_id相同的分区内，数据首先按product_id排序，然后按highlight_strength排序。
当尝试执行以下查询时：
err = session.Query("select product_id from global_product_highlights where category_id=? order by highlight_strength DESC",default_category).Scan(&prodId_array)即使在category_id上创建了二级索引，Cassandra也会报错：“ORDER BY with 2ndary indexes is not supported.”。这个错误并非直接指出二级索引与ORDER BY不兼容，而是揭示了ORDER BY子句的根本限制。
ORDER BY子句的工作原理
Cassandra的ORDER BY子句有严格的规定：它只能应用于聚簇键中的第一个列。在上述global_product_highlights表中，第一个聚簇列是product_id。这意味着，如果你想对查询结果进行排序，你只能基于product_id进行升序或降序排序，例如：
SELECT product_id FROM global_product_highlights WHERE deal_id = 'some_deal_id' ORDER BY product_id DESC;
尝试对highlight_strength进行排序会失败，因为highlight_strength是第二个聚簇列，而不是第一个。Cassandra的这一设计是为了优化查询性能，因为它避免了在查询时进行昂贵的即时排序操作，而是依赖于数据预先存储的顺序。
二级索引与ORDER BY的误区
二级索引在Cassandra中用于在非主键列上启用查询，尤其是在你不知道分区键的情况下。然而，二级索引并不会改变数据的物理存储顺序，也无法赋予ORDER BY子句额外的排序能力。它们仅提供了一个查找机制，一旦数据被检索出来，其排序仍然由原始的主键定义决定。因此，在category_id上创建二级索引，并不能让你通过category_id过滤后，再按highlight_strength排序。
解决方案：重新设计表结构
要解决这个问题，你需要根据你的主要查询需求来重新设计表的PRIMARY KEY。如果你需要根据highlight_strength进行排序，那么highlight_strength必须成为聚簇键中的第一个列。
假设你的主要查询模式是根据deal_id和category_id查找产品亮点，并按highlight_strength排序，那么你可以考虑以下两种设计：
方案一：将highlight_strength作为第一个聚簇列
如果你最常需要按highlight_strength排序，可以调整主键结构：
CREATE TABLE global_product_highlights_by_strength ( deal_id text, category_id text, highlight_strength double, product_id text, creation_date timestamp, rank int, PRIMARY KEY ((deal_id, category_id), highlight_strength, product_id) );
在这个新的设计中：
- deal_id和category_id组成复合分区键。这意味着所有具有相同deal_id和category_id的数据将存储在同一个分区中。
- highlight_strength是第一个聚簇列，product_id是第二个聚簇列。
- 现在，你可以在查询时按highlight_strength进行排序：
-- 假设你想查询某个deal_id和category_id下的产品，并按highlight_strength降序排列 SELECT product_id FROM global_product_highlights_by_strength WHERE deal_id = 'some_deal_id' AND category_id = 'some_category_id' ORDER BY highlight_strength DESC;
注意事项：
- 这种设计要求你在查询时必须提供deal_id和category_id来命中特定的分区。
- ORDER BY子句现在可以作用于highlight_strength。
方案二：如果category_id仅用于过滤，且不作为分区键的一部分
如果category_id只是一个过滤条件，并且你仍然希望以deal_id作为主要分区键，并且能够按highlight_strength排序，那么highlight_strength需要成为deal_id之后的第一聚簇列。但这通常意味着你无法在不指定deal_id的情况下，仅通过category_id和highlight_strength进行高效排序查询。
CREATE TABLE global_product_highlights_sorted_by_strength ( deal_id text, highlight_strength double, product_id text, category_id text, creation_date timestamp, rank int, PRIMARY KEY (deal_id, highlight_strength, product_id) );
在这种情况下，你可以按highlight_strength排序，但如果你想通过category_id过滤，你仍然需要一个二级索引：
CREATE INDEX ON global_product_highlights_sorted_by_strength (category_id);
然后，你可以执行以下查询：
-- 这个查询依然会报错，因为二级索引不能改变ORDER BY的限制 -- SELECT product_id FROM global_product_highlights_sorted_by_strength -- WHERE category_id = 'default_category' ORDER BY highlight_strength DESC;
重要提示： 即使有了二级索引，如果你的WHERE子句中没有分区键，并且你尝试对非第一个聚簇列进行ORDER BY，Cassandra仍然会拒绝。二级索引允许你查询非主键列，但它不会改变ORDER BY的规则。只有当你的WHERE子句包含了分区键，并且ORDER BY作用于第一个聚簇列时，查询才能成功。
总结与最佳实践
- Cassandra的ORDER BY子句仅支持主键中的第一个聚簇列。
- 二级索引不提供排序能力。 它们只是为了在非主键列上进行高效查询。
- 表设计必须以查询模式为驱动。 如果你的应用程序需要按特定列排序，那么该列必须是聚簇键中的第一个。
- 重新评估你的主键设计。 根据最频繁和最重要的查询需求，调整分区键和聚簇键的顺序。这可能意味着你需要创建多个表，每个表针对不同的查询模式进行优化（数据冗余在Cassandra中是常见的模式）。
- 在设计Cassandra表时，始终考虑数据如何被访问，特别是涉及到排序的场景。这将帮助你构建一个高效且无错误的数据库模式。
