使用LIMIT和OFFSET遍历Cassandra大表是否存在意外副作用？

你的方案在小测试环境能正常运行，但放到生产5节点集群的超大表上风险极高，核心问题在于Cassandra的分布式架构和OFFSET的实现机制：

为什么LIMIT+OFFSET不可行？ #

• 性能灾难：Cassandra的OFFSET并非直接跳过前面的数据，而是需要扫描从表开头到OFFSET位置的所有数据后，再返回LIMIT条结果。随着OFFSET值不断增大，每次查询需要扫描的数据量会线性增长，后期单次查询可能要扫描数百万甚至上亿条数据，直接导致节点CPU、IO、带宽被占满，出现查询超时，甚至拖垮整个集群。
• 数据一致性问题：遍历过程中如果有数据插入、删除或更新，OFFSET是基于查询时的结果集计数，会引发重复读取或漏读数据的问题。比如某页查询完成后，前面有数据被删除，下一页的OFFSET会跳过正确的数据；或者新数据插入到前面区域，会被重复读取。
• 递归栈溢出：如果表数据量极大（比如几千万条），递归调用次数会非常多，很快就会触发StackOverflowError，导致程序崩溃。

正确的全表遍历方案：基于Token或主键分页 #

Cassandra设计时就推荐用Token分页或者主键范围分页来实现全表遍历，避免全表扫描带来的性能问题。

1. Token分页（最通用的方案） #

每个Cassandra分区都有唯一的token值，我们可以通过token的范围来逐页查询：

• 第一页：SELECT token(partition_key), * FROM table LIMIT N
• 后续页：SELECT token(partition_key), * FROM table WHERE token(partition_key) > ? LIMIT N（?为上一页最后一条数据的token）

这种方式每次只扫描后续的分区，不会重复扫描前面的数据，性能稳定且可控。

2. 基于主键的分页（适合有复合主键的表） #

如果你的表有复合主键（比如(partition_key, clustering_key)），可以按分区+聚类键的范围查询：

• 先获取所有分区键：SELECT DISTINCT partition_key FROM table
• 对每个分区，逐页查询：SELECT * FROM table WHERE partition_key = ? AND clustering_key > ? LIMIT N

这种方式适合数据按分区分布均匀的场景，能减少跨节点查询的开销。

修改后的代码示例（Token分页+循环代替递归） #

把递归改成循环避免栈溢出，同时用token分页实现稳定遍历：

private void migrateBookingTable(Database database, Statement statement, String tableName, int limit) throws SQLException, LiquibaseException {
    String lastToken = null;
    boolean hasMoreData = true;

    while (hasMoreData) {
        StringBuilder sqlBuilder = new StringBuilder("SELECT token(booking_id), * FROM ").append(tableName);
        if (lastToken != null) {
            sqlBuilder.append(" WHERE token(booking_id) > ").append(lastToken);
        }
        sqlBuilder.append(" LIMIT ").append(limit);

        try (ResultSet resultSet = statement.executeQuery(sqlBuilder.toString())) {
            // 检查是否还有数据
            hasMoreData = resultSet.isBeforeFirst();
            if (!hasMoreData) {
                break;
            }

            String currentPageLastToken = null;
            while (resultSet.next()) {
                // 获取当前行的token（注意：token列是查询的第一列）
                currentPageLastToken = resultSet.getString(1);
                // 处理业务逻辑
                // some logic
            }

            // 提交当前页的处理结果
            database.execute...
            // 更新lastToken，用于下一页查询
            lastToken = currentPageLastToken;
        }
    }
}

额外注意事项 #

• 批量大小调整：limit不要设置太大（建议1000-5000条），避免单次查询返回过多数据导致内存溢出，同时减少集群压力。
• 数据一致性处理：如果迁移过程中有数据写入，建议在维护窗口暂停写入，或者在迁移完成后做一次补查，确保没有遗漏数据。
• 监控集群状态：生产环境迁移时，要实时监控节点的CPU、内存、磁盘IO和查询延迟，避免影响正常业务。

内容的提问来源于stack exchange，提问作者Tristate