检索数据时使用 ORDER BY 这与表定义中指定的顺序相同，然后cassandra只是“跳转”到区域的开头，然后线性地读取数据。当你有 ORDER BY 相反，它稍微贵一点，但并不重要。但是要小心，如果您颠倒第一个集群列的顺序，那么其余集群列的顺序将会改变。

好吧，假设我有一张table，用来跟踪顾客购买的音乐专辑：

CREATE TABLE customers_by_album (
  album TEXT,
  band TEXT,
  custno INT,
  customer_name TEXT,
  PRIMARY KEY (album,custno))
WITH CLUSTERING ORDER BY (custno ASC);

一旦我插入一些数据并运行 nodetool flush （强制到磁盘），我将运行以下查询，翻转排序方向：

aaron@cqlsh:stackoverflow> SELECT album,token(album),band,custno,customer_name
    FROM customers_by_album
    WHERE album='Moving Pictures'
    ORDER BY custno DESC;

当我查询分区键时 album ，的 album 的价值 Moving Pictures 散列为7819329704333693835的标记。节点10.0.0.5负责令牌7819329704333693835，并在那里发送查询。假设行/键缓存未命中，cassandra将前往目录 stackoverflow/customers_by_album-e2820d00d88311e9b9dc413ae9a4e561/ 并找到相应的sstable文件。
在文件中，它找到分区并开始按顺序读取：

一旦读取了请求的数据，它现在必须反转刚刚读取的数据的排序方向，返回以下结果：

album           | system.token(album) | band | custno | customer_name
-----------------+---------------------+------+--------|---------------
 Moving Pictures | 7819329704333693835 | Rush |     14 | Mitch
 Moving Pictures | 7819329704333693835 | Rush |     13 | Jeff
 Moving Pictures | 7819329704333693835 | Rush |     12 | Ted
 Moving Pictures | 7819329704333693835 | Rush |     11 | Aaron

(4 rows)

与排序方向的翻转相关的成本似乎很小。当我用 TRACING ON ，我得到一个20.217ms的结果 ORDER BY custno ASC （排序方式的排序方向与磁盘上的排序顺序匹配）我在10.98毫秒内得到一个结果。
现在想象一下，在分区中存储上万行，向后拉几十列，然后翻转排序方向。我曾与一些应用程序团队合作过，他们对大型结果集的查询会在whey翻转排序方向时超时。因此，更改排序方向的“成本”肯定与读取的行/列数成正比。