问题背景
在使用 Elasticsearch 进行大量数据迁移时，遇到了 bulk 写入性能严重下降的问题。虽然 bulk 请求都返回成功，但实际写入的文档数量远低于预期，且写入速度非常慢。
排查过程
第一轮：怀疑索引设计问题
现象：
- Bulk 写入速度慢
- 写入的文档数量远低于预期
假设：
可能是索引设计不合理，分片数过多或单个索引文档数过多导致性能问题。
尝试的解决方案：
- 减少分片数（从 6 个减少到 3 个）
- 降低单个索引的文档上限（从 80 万降低到 40 万）
结果：
问题依然存在，写入速度没有明显改善。
第二轮：怀疑并发写入导致资源竞争
现象：
- 同时有多个迁移任务在运行
- 怀疑是写入线程池被占满
假设：
多个 bulk 写入任务并发执行，导致 Elasticsearch 的写入线程池资源竞争，从而影响性能。
尝试的解决方案：
停止其他迁移任务，只保留一个任务运行。
结果：
问题依然存在，说明不是并发写入导致的资源竞争问题。
第三轮：发现 _id 冲突导致大量覆盖操作
关键发现：
通过分析 Elasticsearch 的索引统计信息，发现docs.deleted数量异常高，几乎与
)
!)