reindex 8000 万文档跑了 8 小时 slices 默认 1 怎么提速

重建索引任务跑了八小时，_tasks 里 processed 才 3000 万，status 一直没变化。目标索引副本数是 1，源索引有 12 个分片。乍看像缓存或者权限的锅，追下去往往不是。

POST _reindex?wait_for_completion=false&slices=auto
{"source": {"index": "orders_v1", "size": 5000},
"dest": {"index": "orders_v2"}}

追下去是这么回事：reindex 默认 slices 是 1，只有一个线程读源分片再写目标，多分片的并行度完全没利用。目标索引还在同步写副本，写入量翻倍。批量大小默认 1000，网络往返次数也多。

「reindex 提速」相关的日志我一般连着看前后五分钟，单看一条报错经常判断不出是哪一步失败。一次只改一处，改完立刻验证，几个改动叠在一起，出问题就说不清是谁导致的。

先做最小复现，能稳定跑出来的问题，排查成本会低一个数量级。别只看报错的最后一行，往上看几行，真正的起因通常在上面。

具体做法是，重建期间把目标索引副本数设为 0 完成后再加回来；slices 设成 auto 或按源分片数给；调大 batch_size 到 5000 左右 观察堆和 429；用 _tasks 盯 processed 和 created 的增速。

验收就看一点，_tasks 里 processed 每小时增长明显加快，总耗时压到三小时内，文档数与原索引一致。