配置:
ES存储了2-3亿条，几百GB
ES集群有5 个节点
2主2副
ES返回数据量窗口大小设置
index.max_result_window
深度翻页
1.from + size 方式
2.scroll相当于维护了一份当前索引段的快照信息，这个快照信息是你执行这个scroll查询时的快照。在这个查询后的任何新索引进来的数据，都不会在这个快照中查询到。
但是它相对于from和size，不是查询所有数据然后剔除不要的部分，而是记录一个读取的位置，保证下一次快速继续读取
缺点：
「scroll_id会占用大量的资源（特别是排序的请求）」
同样的，scroll后接超时时间，频繁的发起scroll请求，会出现一些列问题。
「是生成的历史快照，对于数据的变更不会反映到快照上。」
「优点：」
适用于非实时处理大量数据的情况，比如要进行数据迁移或者索引变更之类的。
3.es维护一个实时游标，它以上一次查询的最后一条记录为游标，方便对下一页的查询，它是一个无状态的查询，因此每次查询的都是最新的数据。
由于它采用记录作为游标，因此**「SearchAfter要求doc中至少有一条全局唯一变量（每个文档具有一个唯一值的字段应该用作排序规范）」**
「优点：」
无状态查询，可以防止在查询过程中，数据的变更无法及时反映到查询中。
不需要维护scroll_id，不需要维护快照，因此可以避免消耗大量的资源。
「缺点：」
由于无状态查询，因此在查询期间的变更可能会导致跨页面的不一值。
排序顺序可能会在执行期间发生变化，具体取决于索引的更新和删除。
至少需要制定一个唯一的不重复字段来排序。
它不适用于大幅度跳页查询，或者全量导出，对第N页的跳转查询相当于对es不断重复的执行N次search after，而全量导出则是在短时间内执行大量的重复查询。
