企业官网建设流程全解析

我大概在2015年前后第一次在生产环境里认真用ElasticSearch，那时候项目里有个电商后台，商品数据到了几十万条，MySQL的LIKE查询已经明显开始拖后腿，尤其是用户输入“红色连衣裙女夏”这种带分词需求的关键词时，SQL怎么写都别扭，查出来还不准确。后来换了ES，第一次感受到什么叫做“搜索是独立于存储的一层能力”。这十多年里，我用ES搭过站内搜索、日志平台、推荐系统的召回层，也踩过不少坑。今天这篇汇总，就是把这些年关于ElasticSearch的实践经验做个系统梳理，从Windows下的安装启动、索引分词设计、检索调优，到集群部署的取舍，尽量把搜索引擎从入门到能用的完整链路讲透，适合正准备用ES做站内搜索或日志平台的读者，也适合已经上手但总感觉哪里不对的同学对照排查。

1. 为什么站内搜索最终都会绕不开ElasticSearch

先聊一个比较根本的问题：为什么我们做搜索功能的时候，最终都会选ElasticSearch，而不是继续用数据库自带的能力硬扛。

1.1 数据库LIKE查询和搜索引擎的本质差异

很多项目在早期数据量小的时候，用WHERE title LIKE '%关键词%'也能应付。但一旦数据涨到一定量级，比如几十万上百万条，问题就接踵而至。首先是性能问题，LIKE查询无法走常规索引，全表扫描的成本会随着数据量线性上升；更关键的其实是搜索效果问题——用户搜索“笔记本”的时候，你很难用LIKE去匹配到标题为“联想拯救者Y9000P 2024款电竞本”这条数据，因为分词和同义词扩展这类能力，关系型数据库默认是不提供的。

ElasticSearch解决的核心问题，就是把“匹配”这个动作从“遍历比较”升级成了“倒排索引查找”。ES在写入文档时会先做分词，把“红色连衣裙女夏”拆成“红色”“连衣裙”“女”“夏”等词项，然后建立词项到文档ID的反向映射。查询的时候，用户输入同样经过分词，直接在倒排索引里找词项对应的文档列表，再做评分排序。这个过程，本质上和字典查字是一样的逻辑，而不是从头到尾翻一遍书。

1.2 我理解中的ElasticSearch适用边界

ES不是万能的，它最擅长的场景有三个。第一个是站内全文搜索，比如电商商品搜索、文档库检索、论坛帖子搜索；第二个是日志与指标分析，也就是经典的ELK技术栈，Filebeat采集日志，Logstash或Ingest Pipeline做清洗，ES存储和分析，Kibana做可视化；第三个是搜索推荐系统的召回层，用ES做初筛，把候选集缩小后再交给更重的排序模型。

但ES并不适合做事务处理，它不支持跨文档的事务，也不适合做复杂的多表关联查询。有些人拿ES当主数据库用，存核心业务订单，这个我劝你慎重。ES的定位是搜索和分析引擎，可靠的持久化存储还是应该交给关系型数据库，这也是为什么现在主流架构都是MySQL或PostgreSQL负责OLTP，ES负责搜索，两边通过同步机制保证数据一致。

1.3 为什么升级到9.x之后仍然值得学习

最近热词里出现了“elasticsearch 9.4 部署”，说明很多人已经开始关注新版本。ES从8.x开始默认开启了HTTPS和身份认证，安全性大幅提升，同时引入了更简单的部署方式。9.x延续了这些变化，并且对向量检索的支持更成熟，JVM版本要求也更高了。

不过说实话，对于大多数刚入门的人来说，8.x和9.x的核心概念完全一致——索引、分片、副本、分词器、倒排索引、Query DSL，这些二十年前就有的东西到今天依然是基本功。新版本更多是在兼容性、性能、安全方面的持续完善。所以这篇汇总里的原理和操作，在9.x以及当前主流的8.x版本上都适用，我会尽量在涉及具体操作时标注版本差异。

2. Windows环境安装ElasticSearch的正确姿势与启动踩坑

热词里有一串关于Windows安装和启动ES的搜索：“elasticsearch windows”“windows启动elasticsearch”“elasticsearch安装”。这确实是最容易出问题的环节，ES本身是Java写的，但它启动时的坑和普通Java应用不太一样，很多人在第一步就卡住。

2.1 安装前的准备：JDK版本和目录规范

ES 8.x和9.x对JDK版本有明确要求，通常需要JDK 17或更高版本。ES在安装包内其实自带了JDK（在jdk目录下），如果你不想折腾环境变量，直接用自带的就行。不过我自己习惯单独安装JDK，因为这台机器上可能还要跑其他Java程序，统一管理更省心。

装JDK的时候要注意，别光看java -version能输出版本号就以为万事大吉，ES启动脚本对JAVA_HOME环境变量的要求比较严格。Windows下设置完环境变量之后，一定要新开一个终端窗口再验证，因为旧窗口不会刷新环境变量，这是很多人装完JDK之后ES依然报“找不到Java”的原因。

目录规范方面，我强烈建议ES的安装目录路径里不要带空格，也不要有中文。比如D:\Software\ElasticSearch就很好，但C:\Program Files\elasticsearch-9.4.0这种带空格的路径，在某些脚本处理和后续安装插件的时候，容易引发莫名其妙的路径解析问题。你可能会觉得这不至于吧，但我在实践中真的遇到过插件安装脚本因为空格路径而失败的情况，绕了一圈才发现是目录的问题。

2.2 Windows下启动与常见报错排查

解压安装包之后，进入bin目录，双击elasticsearch.bat或者在当前目录打开终端执行：

.\elasticsearch.bat

这里有一个很多新手会忽视的细节：ES默认不允许用管理员权限运行。如果你在Windows上右键“以管理员身份运行”终端，再启动ES，它反而会报错，大概意思是“不要用root或管理员身份运行ElasticSearch”。这个设计是为了防止误操作导致文件权限混乱。正确的做法是使用普通用户打开终端执行启动命令。

启动过程如果能看到[INFO]级别的日志，并且最后出现类似Active License is now [BASIC]; Security is enabled的提示，说明已经成功了。然后用浏览器访问：

https://localhost:9200

8.x之后默认启用了HTTPS，浏览器访问的时候会提示证书不受信任，这是正常的，选择“继续访问”即可。然后输入安装过程中自动生成的用户名elastic和密码。首次启动时ES会在控制台输出一个随机生成的密码，你一定要先复制保存下来，错过了就只能在config/elasticsearch.yml里手动设置或重置。

另一个Windows下特别常见的坑是JVM堆内存设置。ES默认堆内存是1GB，对于开发学习够用，但如果你是在自己的电脑上做测试、导入了较大数据集，1GB很容易触发内存压力。修改方式是在config/jvm.options文件里调整：

-Xms2g -Xmx2g

注意Xms和Xmx必须设置成相同的值，避免堆动态伸缩带来的性能损耗。另外，不要超过物理内存的一半，因为ES还需要大量堆外内存做文件缓存和网络缓冲。

2.3 我用过的Windows开发环境补充建议

如果你是Windows用户，我建议额外做三件事：

• 安装ElasticSearch的head插件可视化工具，不过现在更推荐直接用Kibana的Dev Tools，功能更全面。
• 在config/elasticsearch.yml里设置cluster.name和node.name，这样在日志里能清晰分辨不同节点。
• 关闭系统休眠或调整电源计划为“高性能”，否则笔记本在使用电池时可能会因为CPU降频导致ES响应变慢，你会误以为是配置问题。

3. 索引与分词设计：搜索引擎准不准，根源在这里

很多人觉得ES难学，倒不是难在怎么启动和查询，而是难在设计——索引怎么建、字段用什么类型、分词器怎么选，这些决策直接影响搜索结果准不准，而且一旦上线之后改起来就是大工程。

3.1 理解倒排索引：ES为什么这么快

ES的索引（Index）在概念上类似于关系型数据库里的“表”，但这只是便于理解的类比，底层机制完全不同。ES的底层是基于Lucene的倒排索引结构。举个例子，有两篇文档：

• 文档1标题：“苹果手机最新报价”
• 文档2标题：“苹果园采摘攻略”

经过分词后，倒排索引大致是这样的：

当你搜索“苹果手机”的时候，ES先在倒排索引里找到“苹果”对应的文档列表，再找到“手机”对应的文档列表，然后对两个列表做合并计算。整个过程不涉及扫描全文档，所以速度极快。

这个机制也解释了为什么ES的“相关性”和数据库的“等于”完全不同——ES是在词项级别做匹配和打分，而不是在完整字段上做字符比较。

3.2 Mapping设计：字段类型选错，事后想改就难了

Mapping相当于ES里的表结构定义，决定每个字段如何被索引和存储。设计Mapping时最大的坑是：ES支持动态映射，也就是你不定义Mapping，它也会根据第一条数据自动推断字段类型。这个功能开发时很方便，但生产环境我劝你关掉或用strict模式，否则数据格式一旦发生变化，类型冲突就会导致写入失败。

以商品搜索为例，一个比较合理的Mapping骨架长这样：

{ "mappings": { "properties": { "title": { "type": "text", "analyzer": "ik_max_word", "search_analyzer": "ik_smart" }, "category": { "type": "keyword" }, "price": { "type": "double" }, "brand": { "type": "keyword", "fields": { "text": { "type": "text" } } }, "publish_time": { "type": "date", "format": "yyyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis" } } } }

几个关键决策点解释一下。text类型是全文类型，会经过分词器处理，用于模糊搜索和关键词匹配；keyword类型是精确类型，不进行分词，适合filter、排序和聚合操作，比如品牌、分类、状态这些字段。价格用double还是scaled_float取决于精度要求，scaled_float在存储上更高效，适合金额字段。时间字段一定要指定format，不然不同来源的数据格式不一致时，ES会解析失败，这个问题我在同步MySQL数据时遇到过很多次。

字段是否需要被搜索、是否需要被聚合、是否需要展示原始值，这三个问题直接决定了字段用什么类型、需不需要fields多字段配置。比如品牌字段，既要支持精确筛选，又要支持模糊搜索，就可以上面这样用keyword加text子字段的方式同时满足。

3.3 分词器的选择：中文搜索引擎的胜负手

英文分词天生有空格，ES默认的Standard Analyzer就能处理得不错。但中文分词就麻烦了，字与字之间没有天然边界，需要用专门的中文分词器。目前我用得最多的是IK分词器（analysis-ik），它支持ik_max_word（最细粒度切分）和ik_smart（最粗粒度切分）两种模式。

简单解释一下二者区别。ik_max_word会把“中华人民共和国国歌”尽可能多地切分成各种可能的词：“中华人民共和国”“中华人民”“中华”“华人”“人民共和国”“人民”“共和国”“国歌”等。这种模式索引时用，能提高召回率。ik_smart则只切出“中华人民共和国”“国歌”这种最合理的粗粒度词，查询时用，能提高准确率，减少噪音。这就是为什么Mapping里我会设置analyzer为ik_max_word、search_analyzer为ik_smart。

安装IK插件的方式是在ES目录下执行：

./bin/elasticsearch-plugin install https://github.com/medcl/elasticsearch-analysis-ik/releases/download/v9.0.0/elasticsearch-analysis-ik-9.0.0.zip

版本号要根据你的ES版本选择匹配的IK版本，否则插件加载会失败。安装完插件需要重启ES才能生效。IK还支持自定义词典，比如你的业务里有“超跑”“盲盒”这些互联网新词，可以维护在IKAnalyzer.cfg.xml配置的自定义词典文件里，这个能力在垂直领域搜索中极其重要。

这里补充一个经验：不要为了省事，把所有text字段都用同一个分词器。像商品名称和商品描述，虽然都是文本，但检索精确度要求完全不同。商品名称适合ik_max_word保证召回，描述字段可以考虑standard分词或干脆不索引，只在需要时通过source字段展示原始内容。分词粒度是精确率和召回率的平衡，不存在一个放之四海而皆准的分词器。

4. 检索语法与查询调优：把DSL写对，性能差一个数量级

查询是ES最常用的操作，但同一个需求，不同的DSL写法，性能差距很大。这一章我梳理的是最有实用价值的查询语法和调优经验。

4.1 一个查询的完整结构：Query与Filter的分离

ES查询分两个上下文，这是理解DSL最核心的一点。query上下文是相关性评分上下文，会计算每个文档的得分，用于排序；filter上下文是过滤上下文，只做条件匹配，不参与评分，而且可以被缓存。

实际项目里“电脑”这种关键词属于query上下文，而“价格小于5000”“品牌是苹果”“库存大于0”这些条件应该放进filter上下文。这样做的好处是过滤条件不计算评分，执行更快，而且相同条件的filter结果会被ES自动缓存，后续相同查询直接走缓存。

一个看起来还比较清晰的查询示例：

{ "query": { "bool": { "must": [ { "match": { "title": "苹果手机" } } ], "filter": [ { "term": { "status": 1 } }, { "range": { "price": { "lte": 8000 } } } ] } }, "from": 0, "size": 20, "sort": [ { "publish_time": { "order": "desc" } } ] }

match是全文检索，适合搜索框输入的关键词，会做分词匹配；term是精确匹配，适合id、状态、分类这类keyword字段。很多新手会把term用在text字段上，然后发现什么都查不到。这是因为text字段在索引时被分词了，原始输入的“苹果手机”和索引中的词项“苹果”“手机”并不完全相等。如果你确实需要对文本做精确匹配，应该用keyword类型字段，或者match_phrase。

4.2 中文搜索的高频坑：match_phrase和should的误用

做站内搜索时，用户经常输入“苹果手机最新价格”这类长句。如果用match，ES会把它分词后做OR匹配，查出来的结果里只要包含“苹果”也可能排前面，准确率不高。但如果你直接换成match_phrase要求所有词按顺序出现，又会导致召回率太低，“苹果手机”和“手机苹果”的匹配预期很难两全。

我的经验是配合minimum_should_match参数来控制宽松度：

{ "match": { "title": { "query": "苹果手机最新价格", "minimum_should_match": "70%" } } }

这个参数的意思是，查询词项中至少70%需要匹配上，这样在保证召回的同时不会让噪音文档排太前。具体比例要根据索引数据情况反复试，我一般先从60%起步，再根据搜索结果和用户反馈调整。

另外，should语境也容易踩坑。should子句在bool查询中表示“或”语义，但要注意它只有在没有must或filter子句的时候才是必选条件，一旦存在must或filter，should就退化成加分项，不会强制过滤。很多人在做“标题或描述包含关键词”这类查询时，以为加上should就会匹配，结果发现完全不搭边的结果也出来了，原因就在这个语义上。

4.3 深度分页与聚合的性能陷阱

ES默认的from + size分页方式，在数据量小的时候没问题，但一旦页码深了，性能会急剧下降。因为ES需要把每个分片上前from + size条结果全部取出来，然后做全局排序，最后才返回当前页的数据。你查第10000页，实际上每台机器都取了前100010条数据来排序。这个设计在小数据量下无害，在几十亿条日志场景下就是灾难。

推荐的替代方案有两个。如果是用户需要跳页的场景，使用search_after，它基于上一页最后一条数据的排序值继续往后取，性能稳定，但代价是不支持跳页。如果是日志分析这类场景，更推荐直接禁用深度分页，只允许翻前100页。代码如下：

{ "search_after": [ "2024-01-15 10:23:45", 56372 ], "sort": [ { "publish_time": "asc" }, { "_id": "asc" } ] }

注意search_after要求排序字段的值必须唯一，否则翻页时容易漏数据或重复，所以通常加一个_id作为第二排序字段。

聚合（Aggregation）的坑也很典型。ES聚合是在分片级别先做局部聚合，再做全局合并。如果某个字段的基数特别高，比如对用户ID做聚合，而且分片数量又特别多，内存压力就会很大。经验做法是：尽量对keyword字段聚合，text字段必须先改成keyword子字段才能聚合；聚合时合理设置size，不要无脑拉全量桶；超大基数聚合优先考虑用composite聚合替代普通terms聚合，支持分批滚动取数，内存可控。

4.4 查询性能优化的体检清单

排查线上ES查询慢，我一般按下面这个清单逐项查：

1. 确认是否有慢查询日志，index.search.slowlog.threshold.query.warn这类配置有没有开。
2. 用_explain接口分析某个文档为何不匹配，确认分词结果是否符合预期。
3. 检查查询是否命中了缓存，filter 条件是否在复用。
4. 确认分片数是否合理，单分片数据量是否过大。
5. 观察JVM堆内存使用率和GC频率，如果Old Gen持续增长并且Full GC频繁，基本可以判定是聚合或深分页导致的压力。
6. 分析磁盘IO，段合并是否过于频繁，如果写入压力大，可以适当调大index.merge.scheduler.max_thread_count的并行度或者调节refresh_interval。

我遇到过最经典的案例是：一个电商搜索接口，线上请求P99超过2秒，查了半天发现是每次请求都用了wildcard通配符查询对text字段做模糊匹配，等于数据库的全表扫描。很多模糊搜索的需求，其实通过ngram分词器或match_phrase加前缀查询就能解决，关键是理解ES匹配的执行成本。

5. 数据同步、更新与常见故障排查：线上稳定运行的基石

搜索引擎建好之后，最难的不是查询，而是怎么把业务数据库的数据稳定同步到ES，并且在日常维护中不出幺蛾子。

5.1 全量与增量同步的方案选择

数据同步方案无非三种。第一种是应用双写，在业务代码里写完数据库后同步写ES。优点是实时性好，缺点是侵入性强，而且一旦ES挂了或者数据不一致，很容易影响主流程。第二种是基于日志解析的同步，比如用Canal监听MySQL Binlog，解析后写入ES。实时性和可靠性都很好，但架构复杂，需要额外维护Canal服务。第三种是基于定时任务的全量或增量同步，实现简单，适合实时性要求不高的场景。

我个人的建议是：小项目用定时任务+MYSQL增量字段（比如update_time），每天增量同步一次完全够用；中大型项目上Canal，做实时同步；不要轻易选择应用双写，除非你有完善的补偿机制和异步队列兜底。

增量同步有个容易忽略的细节：MySQL的update_time精度如果只到秒，同一秒内的并发更新可能漏掉。建表时update_time字段建议用datetime(3)精度到毫秒。另外，同步任务除了增量，还要定期做一次全量校对，把ES和MySQL的数据做比对，修复漏同步或延迟带来的数据差异。这个全量校对很少有人做，但等到数据不一致被用户反馈才发现，代价就大了。

5.2 文档更新为什么不是真的“更新”

ES底层是分段存储的，文档的更新操作实际上是“先删除旧文档，再写入新文档”的标记过程——旧的文档还在磁盘上，只是被打上了删除标记，在段合并时才会被真正清除。这个机制带来的直接影响是，频繁更新文档会产生大量垃圾数据，导致磁盘空间膨胀和查询性能下降。

所以高频更新场景下，有几个实践建议：一是适当调大refresh_interval，默认1秒刷新一次，如果数据实时性要求不那么高，可以调到5秒甚至30秒，减少段刷新次数；二是对日志类数据，不要做更新操作，应该按时间维度滚动创建索引，用索引生命周期管理（ILM）处理；三是对需要频繁更新但又要快速查询的数据，考虑是不是不应该放在ES，或者设计成追加式的文档结构而不是覆盖更新。

5.3 集群状态红色和黄色分别意味着什么

ES集群有三种状态：绿色（所有主分片和副本分片都正常）、黄色（主分片正常但副本分片不可用）、红色（存在主分片不可用）。这是运维中最需要关注的指标。

黄色状态通常意味着某个或某些副本分片分配不成功。原因可能是磁盘空间不足、节点数不足以分配副本，或者分片分配策略配置有问题。红色状态则说明主分片丢了，数据存在丢失风险。遇到红色状态，第一件事是查看是哪些索引的哪些分片出了问题：

curl -X GET "localhost:9200/_cat/indices?v&health=red"

定位到具体索引后，如果主分片所在的节点已经无法恢复，只能通过reroute命令分配副本分片，或者接受丢失后从数据源重建。如果数据源也没有，那就真的无力回天了。这也是为什么我反复强调数据源不能只存在ES里，ES只是检索层的搜索服务，不是数据安全的保险箱。

5.4 磁盘水位和段合并：定时炸弹

ES的磁盘水位线默认是85%触发预警，90%变成只读。一旦集群磁盘使用率超过90%，ES会主动把索引置为只读，写入直接失败。这个机制本来是为了防止磁盘写爆，但在实际运维中，经常因为监控缺失导致业务突然写入失败，而排查时才发现根因是磁盘满了。

建议在运维层面做三件事：一是监控磁盘使用率，超过75%就告警，留出足够缓冲空间；二是定期清理历史索引，或者配置ILM策略让旧索引自动删除或迁移到冷存储；三是理解段合并机制，ES在后台会不断把小段合并成大段，这个过程会消耗大量IO和CPU，如果你的集群在业务高峰期出现周期性卡顿，很有可能就是在做段合并，可以通过_cat/segments查看各索引的段数量，如果数量异常庞大，说明合并跟不上写入速度，需要考虑调大合并线程或降低写入吞吐。

6. 从单机到集群：部署前的容量规划和架构取舍

前面几节基本覆盖了单机ES的日常使用，但搜索引擎一旦成为核心依赖，单机是扛不住的，无论是可用性还是性能，集群部署都不可避免。这一章聊一些我在做集群规划时的思考。

6.1 分片与副本的设置逻辑

分片数在索引创建时确定，后续不能修改，除非重建索引。所以这是建索引时要慎重决策的关键点。分片不是越多越好，每个分片实质是Lucene的一个索引，会产生对应的开销。经验上，单分片的数据量控制在30GB到50GB比较合理，这既能让Lucene的段和缓存效果最大化，又不会因为分片太大导致迁移时间过长。

副本数则相对灵活，一个主分片配一个副本是最基本的，保证节点挂掉时有完整数据。副本不仅提供高可用，还能分担查询压力，ES的查询会轮询到主分片和所有副本分片。所以如果查询压力大，增加副本数可以直接提升读吞吐。但副本也会占用磁盘，写入时也需要同步，不是越多越好。

关于分片数量的计算，业界有一个经验公式：分片数 = 节点数 × 单节点分片数上限。单节点分片数根据内存量级评估，16GB堆内存的节点，分片数控制在500以内比较稳妥。我建议中等规模场景下，一个索引的分片数等于节点数的1到2倍，然后根据实际情况微调。

6.2 单节点多实例到底行不行

经常有人问，测试环境只有一台服务器，能不能在这台机器上跑三个ES节点组成集群。技术上完全可以，ES支持一台机器上启动多个节点，只需要在elasticsearch.yml里设置不同的node.name、http.port和transport.port。但这种模式有一个明显的弱点：如果服务器本身宕机了，三个节点一起挂，集群照样不可用，高可用等于零。

所以单节点上多实例只适合开发测试，用来模拟集群行为，不适合生产环境。生产环境的高可用必须依赖多台物理机或虚拟机，并且节点最好分布在不同的机架或可用区，防止机房级别的故障。

6.3 9.x部署时的架构建议

热词里提到了“elasticsearch 9.4 部署”，在当前的主流架构里，9.x的部署方式相比早期版本已经简化了很多。默认的安全配置，让集群通信与客户端访问都基于HTTPS和证书认证，不需要再像7.x时代那样手动装安全插件。

但新版本也带来了一些新的运维要求，比如JVM版本管理、更严格的权限控制。从8.x升级到9.x时，我建议先在测试环境跑一段时间，用升级助手检查所有API的兼容性，特别是自定义配置项和插件版本。对于存量集群，升级顺序一般是先升级节点，再滚动升级全部节点，过程中保持集群黄色状态，也就是一次只停一个节点，让它恢复之后再操作下一个。

集群规模较大的时候，建议按职责拆分节点类型：master节点只负责集群管理，data节点负责数据存储与查询，ingest节点负责数据预处理。小集群可以混合部署，但一旦超过十个节点，混合部署会影响稳定性——master职责被查询压力挤占后，故障恢复时会出现脑裂风险。

6.4 索引生命周期管理：让ES自治起来

部署和容量规划不是一劳永逸的。日志场景下数据会无限增长，如果不加管控，再大的集群也会被撑爆。ILM（Index Lifecycle Management）是ES内置的策略机制，可以按时间或大小自动执行索引的阶段流转：热阶段（Hot）支持高并发写入，温阶段（Warm）降低存储成本，冷阶段（Cold）进一步压缩存储，删除阶段（Delete）自动清理过期数据。

我常用的一个ILM策略示例是，按天滚动创建索引，30天后自动删除，热数据保留3天，之后转温阶段让副本数和分片数降到最低：

{ "policy": { "phases": { "hot": { "min_age": "0ms", "actions": { "rollover": { "max_primary_shard_size": "50gb", "max_age": "1d" } } }, "delete": { "min_age": "30d", "actions": { "delete": {} } } } } }

ILM是ES运维的重要能力，建议所有日期类索引都配置这个策略，别等磁盘满了再人工清理。

写在最后的一点心得

这些年用ElasticSearch走下来，最深的体会是：搜索引擎的难点不在工具本身，在于你对你业务数据的理解。分词粒度、字段类型、filter与query的边界、分片和副本的分配，这些决策都不是ES教你的，而是业务倒逼你做的。

如果你刚开始学ES，不要急着上集群，先在单机上把一个索引的Mapping、分词器、查询调优跑明白，把Windows环境下安装启动的流程梳理清楚，再谈论部署架构。搜索引擎是一个需要“手感”的东西，多试几次不同参数下的搜索结果，你自然会理解为什么有些数据是keyword，有些是text，为什么倒排索引能让复杂查询快到毫秒级。

之后再遇到“搜索引擎怎么选型”“ES查询为什么慢”“集群怎么规划”这些问题，你脑子里会有一套完整的判断框架，而不是去网上搜一段DSL然后抄过来。这也是这篇汇总真正想帮你建立的东西。