做的事：真实写入100条文档，检查translog的真实状态，再调用显式flush后重新检查
代码真实写入100条文档后: GET /rfc_test/_stats/translog 真实调用: POST /rfc_test/_flush 再检查: GET /rfc_test/_stats/translog
验证：flush之前translog真实有100条操作，flush之后真实被清空归零
实测 · 本机 Elasticsearch 8.15.0 执行输出
flush之前: translog ops=100, size=7347字节 flush之后: translog ops=0, size=55字节（真实只剩空文件头开销）
这组真实结果验证了flush的核心动作：它真实触发了一次Lucene层面的commit——把当前内存里还没正式落盘的段数据真实强制写入磁盘，生成一个真实持久化的检查点。一旦这些写入操作真实已经通过Lucene commit安全落盘，之前为了"防止进程崩溃丢数据"而记录在translog里的那100条操作日志就真实不再需要了，所以flush完成后真实会清空（技术上是生成一个新的translog文件，旧的在安全前提下被清理）translog里已经确认持久化的那部分记录。
真实对比：再写入50条文档后用refresh而不是flush，看translog会不会同样被清空
代码真实再写入50条文档后: GET /rfc_test/_stats/translog # refresh之前 POST /rfc_test/_refresh # 真实只refresh，不flush GET /rfc_test/_stats/translog # refresh之后 POST /rfc_test/_search {"size":0}
验证：refresh真实完全没有动translog，操作数前后都是50；但这50条文档真实已经变得可以被搜索到了
实测 · 本机执行输出
refresh之前: translog ops=50 refresh之后: translog ops=50 ← 真实一个字节都没变，refresh完全没碰translog refresh之后搜索: hits.total=150 ← 真实之前flush的100条+这次新写的50条，全部都能搜到了
这组真实对比精确厘清了refresh和flush两者真实分工完全不同的职责：refresh真实只负责"把内存里缓冲的新文档变成一个可以被搜索引擎扫描到的新Lucene段"，它根本不关心这些数据有没有真实持久化到磁盘的安全检查点，所以它真实完全不会去动translog（因为这些数据真实依然只有translog里的记录能保证进程崩溃后不丢失，直到下一次flush真正做Lucene commit之前）；flush真实负责"把数据真实持久化落盘并清理掉已经不再需要的translog记录"，它关心的是持久性而不是可搜索性（真实flush本身也会顺带做一次refresh，但它的核心职责跟refresh完全不同）。commit这个词在这里真实特指Lucene内部"把一批段数据的变更原子性地固化成一个检查点"这个动作，它真实是flush操作内部真正执行的那个底层步骤，日常使用中很少需要直接操心commit本身，但理解"flush=持久化并清理translog，refresh=让新写入的数据可搜索，commit=flush内部真正执行的Lucene落盘动作"这三者的真实分工，对排查"为什么重启后有数据恢复得慢"或者"为什么磁盘空间涨得比预期快"这类问题非常关键。
分步演示：Refresh、Flush从translog真实状态变化看两者职责分离的完整验证
每一步都是本文上面在本机真实的Elasticsearch 8.15.0上跑出来的原始结果。
flush清空translog做持久化落盘，refresh只负责让数据可搜索完全不碰translog
这一步新验证的操作类型
本文用到的工具
- 本机真实部署的 Elasticsearch 8.15.0（单节点，tar包直接启动）
- 真实的
_flush、_refreshAPI与_stats/translog
下一篇 · ELASTICSEARCH 96
Translog 如何保证写入恢复
京公网安备11010502063487号