因此，我有一个物化视图定义如下（稍微更改了名称）：

CREATE MATERIALIZED VIEW MYVIEW AS
    SELECT *
    FROM XXXX
    WHERE id IS NOT NULL AND process_on_date_time IS NOT NULL AND poller_processing_status IS NOT NULL
    PRIMARY KEY (poller_processing_status, process_on_date_time, id)
    WITH CLUSTERING ORDER BY (process_on_date_time ASC, id ASC)
...

根据定义，数据将按asc顺序（最早的第一个）中的process\u on\u date\u time列进行排序。
现在有一个查询运行如下：

SELECT JSON * FROM MYVIEW
WHERE poller_processing_status='PENDING'
AND process_on_date_time<=1548775105000  LIMIT 250  ;

匹配的行超过250行，因此返回250行。从cqlsh运行它，它获取3次—前两次获取100行，最后一次获取50行。我启用了通过cqlsh和consistency local\u one进行跟踪。现在，在前两次抓取中，它们执行完全相同的步骤，顺序相同，表相同，等等。其中一次总是需要2秒，另一次是8毫秒。我一辈子都搞不明白为什么一次要花2秒以上。慢家伙拖延了“来自memtables和sstables的合并数据”（但同样，前两次获取做的事情完全相同，但一次是慢的，另一次是快的-相同的合并sstables）。
继续执行步骤2。我想，好吧，我们有一个聚类列，所以它被排序了。如果我添加一个orderby子句来对结果进行排序呢。所以我运行了这个：

SELECT JSON * FROM sop_cas.notification_by_status_ptd_mv
WHERE poller_processing_status='PENDING'
AND process_on_date_time<=1548775105000
ORDER BY process_on_date_time ASC LIMIT 250  ;

因此基本上是完全相同的查询，以与排序数据（聚类列）相同的顺序指定顺序。结果？相同-超过2秒完成。没有改善。真倒霉。
最后一个测试。我将查询中的排序从asc改为desc，并尝试了一下。结果？每次查询在10毫秒内响应时。呵呵？？？？这就是我想要达到的目标——但是为什么反向排序运行得很好呢？
我想，当我要求的是比某个东西更老的记录时，asc排序是最好的，因为最老的记录会首先被抓取，然后立即被抓取。另一条路径，desc，我会先有更新的记录，因此必须跳过一堆，找到比我的时间戳早的第一条记录，然后抓取下一条记录。有人能帮我理解这个逻辑吗？为什么desc order by响应良好而asc没有响应。
使用dse 5.1.9
提前谢谢。
-吉姆