Cassandra分区键查询超时：LIMIT与排序异常求助

环境/版本信息 #

• Apache Cassandra 3.11.13
• CQL spec 3.4.4
• Native protocol v4

表结构定义 #

CREATE TABLE table_1 (
    id uuid,
    entity_id uuid,
    event_timestamp timestamp,
    other_field_1,
    other_field_2,
    PRIMARY KEY ((id, entity_id), event_timestamp, other_field_1)
) WITH CLUSTERING ORDER BY (event_timestamp ASC, other_field_1 ASC)
    AND bloom_filter_fp_chance = 0.01
    AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
    AND comment = ''
    AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold': '32', 'min_threshold': '4'}
    AND compression = {'chunk_length_in_kb': '64', 'class': 'org.apache.cassandra.io.compress.LZ4Compressor'}
    AND crc_check_chance = 1.0
    AND dclocal_read_repair_chance = 0.1
    AND default_time_to_live = 0
    AND gc_grace_seconds = 86400
    AND max_index_interval = 2048
    AND memtable_flush_period_in_ms = 0
    AND min_index_interval = 128
    AND read_repair_chance = 0.0
    AND speculative_retry = '99PERCENTILE';

该表分区键为(id, entity_id)，聚类列为event_timestamp和other_field_1，默认聚类顺序为event_timestamp升序、other_field_1升序。

问题描述 #

仅针对某一个分区（数据量小于其他正常分区，其他分区单分区最大210GB仍可正常查询），执行以下三个查询时出现不一致行为：

1. 查询成功

SELECT *
FROM table_1
WHERE id = fe0f352b-0891-479f-b604-2f64a18558d2 
  AND entity_id = 1ead12bd-bd2c-482e-a7ba-5a273903f331
ORDER BY event_timestamp DESC
LIMIT 464;

2. 查询失败，报错Timed out waiting for server response（未指定ORDER BY event_timestamp DESC）

SELECT *
FROM table_1
WHERE id = fe0f352b-0891-479f-b604-2f64a18558d2 
  AND entity_id = 1ead12bd-bd2c-482e-a7ba-5a273903f331
LIMIT 1;

3. 查询失败，报错Timed out waiting for server response

SELECT *
FROM table_1
WHERE id = fe0f352b-0891-479f-b604-2f64a18558d2 
  AND entity_id = 1ead12bd-bd2c-482e-a7ba-5a273903f331
ORDER BY event_timestamp DESC
LIMIT 465;

查询追踪结果 #

cassandra@cqlsh> tracing on;
Now Tracing is enabled
cassandra@cqlsh> SELECT * FROM table_1 WHERE id = fe0f352b-0891-479f-b604-2f64a18558d2 and entity_id = 1ead12bd-bd2c-482e-a7ba-5a273903f331 limit 1;
OperationTimedOut: errors={'x.x.x.x': 'Client request timeout. See Session.execute[_async](timeout)'}, last_host=x.x.x.x
cassandra@cqlsh>

背景补充 #

当LIMIT值较小（如464）时，带降序排序的查询可正常执行；但LIMIT增至465，或者去掉降序排序子句时，就会触发超时错误。已检查Cassandra日志、应用日志及系统日志，未发现明确根因，也没有与tombstone_warn_threshold或tombstone_failure_threshold相关的日志。通过cqlsh、Datagrip、gocql测试，问题均可复现。

待解决问题 #

1. 为何LIMIT从464增至465就触发查询失败？
2. 为何去掉ORDER BY event_timestamp DESC后，即使指定了分区键且表默认聚类顺序为升序，LIMIT 1的查询仍会超时？
3. 如何优化查询或调整参数，让不同LIMIT值的查询都能稳定执行？

问题分析与解决方案 #

1. LIMIT从464增至465触发超时的原因 #

Cassandra处理ORDER BY DESC查询时，会从分区聚类键的末尾（最新的event_timestamp）反向扫描。LIMIT为464时，Cassandra只需扫描到第464条有效数据就返回；但LIMIT到465时，刚好触碰到该分区存在大量墓碑的区域——虽然未触发墓碑阈值日志，但该分区大概率存在批量删除或范围删除产生的大量墓碑，导致Cassandra需要扫描远超465条的实际数据（含墓碑）才能凑够目标行数，最终超过查询超时阈值。另外，Cassandra 3.11的反向扫描性能弱于正向扫描，扫描深度增加时，处理墓碑的开销会显著上升，刚好在465这个临界点触发超时。

2. 无ORDER BY时LIMIT 1超时的原因 #

表默认聚类顺序为event_timestamp ASC，无ORDER BY的查询本应从分区起始位置（最早的event_timestamp）正向扫描取第一条数据。但如果该分区起始区域存在大量墓碑，Cassandra需要持续扫描跳过无效的墓碑行，直到找到第一条有效数据——若起始区域墓碑量极大，扫描时间会超过查询超时限制，导致超时。而带ORDER BY DESC的查询从分区末尾扫描，该区域墓碑量少，所以能快速返回结果。

3. 优化方案 #

（1）清理分区墓碑

• 低峰期手动触发该分区压缩：执行nodetool compact table_1 -k "fe0f352b-0891-479f-b604-2f64a18558d2:1ead12bd-bd2c-482e-a7ba-5a273903f331"，强制压缩该分区以清理墓碑，注意压缩会占用IO资源，需避开业务高峰。
• 排查删除操作：确认是否存在批量/范围删除导致的大量墓碑，后续尽量改用逐行删除（若必须删除）。

（2）调整查询逻辑

• 无ORDER BY的查询显式指定ORDER BY event_timestamp ASC，避免Cassandra执行计划异常（部分版本Cassandra在无ORDER BY时可能误判扫描方向）。
• 分段分页查询：若需获取超过464条数据，使用PAGING STATE分段分页，每次取464条，而非一次性加大LIMIT。
• 适当提高客户端查询超时：如cqlsh的--request-timeout、gocql的Timeout配置，给Cassandra足够时间扫描墓碑。

（3）调整Cassandra配置（谨慎操作）

• 临时调高tombstone_scan_limit：默认值10000，若分区墓碑量超过该值，Cassandra会停止扫描，可临时调至20000，用完后建议调回，避免影响其他查询性能。
• 调高read_request_timeout_in_ms：默认5000ms，若业务允许，可调至10000ms，给查询更多执行时间。

内容的提问来源于stack exchange，提问作者L.T