andy的回答相当完整，但我想补充一些见解，说明为什么返回的页面不完全是所需的大小在当前或未来的实现中可能有用：
cassandra想要返回短页面的一个原因是过滤。假设请求具有allow filtering，并且需要从磁盘读取大量数据，只产生一些行，这些行最终通过过滤器并返回给客户机。客户机没有意识到这一点，要求一个包含1000行的页面—但在我们的示例中，实际生成1000行通过过滤器可能需要10秒，如果cassandra在生成任何结果之前等待10秒，客户机将超时。所以在这种情况下，cassandra应该在超时之前返回它收集到的任何行—即使这些行只有17行而不是1000行。客户端将收到这17行，并正常地继续到下一页。
在极端情况下，可能会有太多的过滤工作，而输出却很少，以至于我们可能有很长一段时间甚至没有一行输出。在这种情况下，在超时之前，cassandra可能会返回一个结果为零的页面，该页面的has\u more位处于打开状态，这意味着客户机应该继续分页（结果数小于请求数，甚至为零，这不是停止分页的标志！）。我不确定cassandra今天是否真的返回了零行页面，但是scylla（一个更快的cassandra克隆版）肯定返回了，而且驱动程序应该记住使用has\u more位作为何时停止分页的唯一标志。
另一个问题是，为什么分页返回的行数比期望的多。正如安迪在回信中所说，我不认为这实际上发生在Cassandra，也不在锡拉。但我可以理解为什么未来的一些实现可能希望它允许这种情况发生：假设一个协调器需要1000行作为一个页面。因此，它从每个副本读取多达1000行数据，但是数据不一致，并且一个副本有一个额外的行，结果是协调器现在有1001行要返回。它只能返回前1000行，但缺点是现在有些副本在数据中的错误位置，需要在被要求读取下一页时重新填充它们的位置。如果我们返回了找到的所有1001行，那么所有副本都将能够从原来的位置高效地恢复读取。

请注意，设置fetch size并不意味着cassandra总是返回确切的行数，它可能返回稍微多一些或少一些的结果
我不相信这个说法是完全正确的。您可以预期页面可能包含小于所需页面大小的内容。例如，如果您的页面大小是10，并且只有8行符合您的查询条件，那么您当然只能返回8行。
但是，我并不熟悉这样一种情况：服务器在一个页面结果中发回的行数超过页面大小。本机协议规范甚至指定返回的消息最多包含以下页面大小：
如果为result\u page\u size提供了正值，则为查询返回的结果消息的结果集最多将包含查询结果的result\u page\u size第一行。
此外，协议规范还规定：
虽然当前的实现总是尊重result\u page\u size的确切值，但出于性能原因，我们保留将来返回稍小或稍大页面的权利。
我不认为这已经被运用，但也许可以解释为什么驱动程序文档是这样措辞的。