推荐直接用scroll()而非scan()，因scan()自7.14+已弃用；scroll()手动管理_scroll_id更可控、内存更稳，配合size=5000、流式写入、_source_includes精简字段及utc时间范围查询，可高效稳定导出百万级日志。
用 elasticsearch-py 的 scan() 还是 scroll()？
直接上 search() 肯定不行——默认只返回前 10 条，且 size 参数硬顶到 10000 就报错。真正导出百万级以上日志，必须用游标式遍历。scroll() 是底层机制，scan() 是它的封装（已从 7.14+ 版本标记为 deprecated），但实际仍可用；更推荐直接用 scroll() + 手动管理 scroll_id，可控性更强、内存更稳。
关键点：
-
scroll参数值不能太小（如"2m"比"10s"更安全），避免游标过期中断 - 每次
scroll()请求必须带上上一次响应里的_scroll_id，漏传或复用旧 id 都会报search_phase_execution_exception - 别在循环里反复调
search()初始化 scroll——那只是浪费请求，初始化一次就够了
如何避免 OOM 和网络超时？
一次性拉 10 万条再写文件？Python 进程大概率被 kill。得边取边写，且控制单次 fetch 数量。
实操建议：
- 初始化
scroll()时设size=5000（不是越大越好，ES 默认index.max_result_window是 10000，但 scroll 不受它限制，不过太大易触发 GC） - 用
csv.writer或jsonlines流式写入，每 1000 条flush()一次，别攒全量再写 - 加
timeout="30s"到每个 scroll 请求，配合requests的max_retries防瞬断 - 导出字段尽量精简：用
_source_includes指定必要字段，比如["@timestamp", "level", "message"]，别传_source=True全量
时间范围查询怎么写才不漏数据？
用 @timestamp 做 range 查询最常见，但容易踩两个坑：时区和精度。
示例（导出 2024-01-01 00:00:00 到 2024-01-02 00:00:00 的日志）：
{
"query": {
"range": {
"@timestamp": {
"gte": "2024-01-01T00:00:00.000Z",
"lt": "2024-01-02T00:00:00.000Z"
}
}
}
}
注意：
- 必须用 ISO8601 UTC 格式（末尾
Z），ES 默认按 UTC 解析，本地时区字符串如"2024-01-01"会被当成 UTC 时间，导致偏移 8 小时 - 用
lt而非lte，避免跨天重复计数（尤其当 timestamp 有毫秒级精度时） - 如果索引按天分片（如
logs-2024-01-01），显式指定index=["logs-2024-01-01", "logs-2024-01-02"]比通配符logs-*更快、更准
导出中途失败了，怎么续传？
scroll 游标本身不支持“跳到第 N 条”，但可以靠 search_after 实现稳定分页——前提是排序字段（如 @timestamp）严格唯一或加 _id 辅助去重。
替代方案（更实用）：
- 把当前处理的
@timestamp和_id记进一个 checkpoint 文件（如 JSON 格式），每次启动先读它，构造search_after查询 - 或者粗粒度按小时切分：先查出所有匹配的
date_histogram桶，每个桶内用 scroll 导出，失败只重跑那个小时 - 千万别依赖
from/size分页做海量导出——深度分页性能断崖式下跌，from=1000000时 ES 可能直接 OOM
scroll_id 生命周期短、不可预测，把它当续传依据风险极高；真正可靠的续传，得靠业务字段（时间戳 + ID）锚定位置。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
