1. 先搞清楚Elasticsearch到底是个什么东西很多人第一次听说Elasticsearch是在公司技术分享会上或者是在招聘JD里看到的熟悉Elasticsearch优先。但真正上手时才发现网上教程要么只讲安装启动要么一上来就丢一堆REST API看得人一头雾水。我自己也是从能在Windows上把ES跑起来到敢在公司生产环境里用它扛日均上亿条日志一路踩坑过来的所以这篇就按我实际的学习路径来写从认识到掌握尽量让你看完能直接动手。1.1 它不是数据库却经常被当成数据库用Elasticsearch简称ES本质上是一个基于Lucene的分布式搜索和分析引擎。它最擅长的不是事务、不是强一致性而是全文检索、海量数据下的实时聚合分析以及毫秒级的查询响应。很多人第一次接触它是因为业务里出现了模糊搜索的需求。比如一个电商后台商品几百万条用户输入红毛衣女如果靠MySQL的LIKE %红毛衣%去查一旦数据量大起来慢是必然的而且无法做到相关性排序。这时候ES就派上用场了它对中文分词、倒排索引、相关性打分都有成熟方案能让你很舒服地实现像百度一样的搜索体验。但它又确实不是传统意义上的数据库。ES没有事务、不支持JOIN虽然有父子文档和nested但用起来远不如SQL顺手、对更新的一致性保证也偏弱。所以实践中它更多是扮演搜索层和分析层的角色数据从业务库同步进来对外提供搜索和统计能力而不是当唯一的数据源去存储关键业务记录。1.2 核心概念速览索引、文档、分片、副本ES里的索引index这个概念最容易让人绕晕。在关系型数据库里索引是表的辅助结构用来加速查询。但在ES里索引就是一个集合级别的概念——你可以把它近似理解成MySQL里的一张表。比如你有订单数据就可以建一个order_index有日志数据就建一个log_index。每个索引里存的是文档document也就是一条条JSON数据。文档是ES里真正存储和检索的单元它不需要提前定义严格的表结构字段可以动态添加这就是ES常说的schema-less。索引底层至少有一个分片shard分片是数据物理存储的最小单位也是ES横向扩展的核心机制。一个索引的数据会被打散到多个分片里分布在集群的不同节点上。副本replica则是分片的拷贝用来提高容错性和查询吞吐。比如你设置了3个主分片和1个副本那么数据就有3份主分片数据加上3份副本数据总共有6个分片实例分布在集群里。我当初学到这里最深的感受是分片数一旦设定就不能在事后随便修改除非重建索引所以前期设计一定要谨慎。新手往往会依赖默认配置1个主分片、1个副本这在数据量小的场景完全够用但如果你预估数据量会到千万级以上一定要提前规划分片数。1.3 与传统数据库MySQL的对应关系用MySQL的思维去理解ES上手会快很多。最直观的对应关系是这样MySQLElasticsearch说明数据库 database集群 cluster通常一套环境就是一个集群表 table索引 index同一类业务数据的集合行 row文档 document一条完整的数据记录列 column字段 fieldJSON里的每个键值对主键 primary key_id文档唯一标识表结构 DDL映射 mapping字段类型和分词规则的定义SQL 查询Query DSL基于JSON的查询语法这个对应关系不是100%精确但足够帮助你建立初步认知。真正实操时你会发现ES的灵活性远高于MySQL但代价是——你需要理解分词、分析器、倒排索引、相关性评分这些全新概念这也是后面所有操作的基础。2. 从零开始安装Windows上把ES和Kibana跑起来搜索热词里windows启动elasticsearch和win11安装elasticsearch和kibana能排这么靠前说明现在还有很多人在Windows环境做本地开发。我最早也是在Windows上折腾的所以这一部分就专门讲讲Windows含Win11下的完整安装启动流程顺便把常见的坑都填一遍。2.1 环境准备JDK版本别选错Elasticsearch底层是Java写的所以必须先有JDK但版本匹配很容易踩坑。ES 7.x系列官方推荐JDK 11或14ES自带了捆绑的OpenJDK如果你不想折腾可以直接用内置的ES 8.x则要求JDK 17。这里有个很重要的细节从ES 7.0开始官方建议不要自己去设JAVA_HOME指向一个不匹配的JDK因为ES自带的JDK已经足够。但如果你偏要用自己的JDK就必须保证大版本一致否则启动时会直接报错Java version mismatch。我建议的做法是先装一个JDK 17并配好JAVA_HOME然后下载ES 8.x版本。这样本地开发完全够用。如果你装的是JDK 8老系统那就去下载ES 7.6.x之类的老版本别硬上新版本。注意Win11下安装JDK有个新变化系统PATH里很可能存在两个Java相关路径一个来自Oracle JDK一个来自Windows自带的OpenJDK。启动ES前在CMD里执行 java -version确认实际生效的版本是你想要的那个否则后面报错会非常莫名其妙。2.2 下载解压与配置elasticsearch.yml里几条关键配置从Elastic官网下载zip包后解压到一个没有中文、没有空格的路径比如 D:\elasticsearch-8.13.0。然后进入config目录重点看elasticsearch.yml。如果你是纯本地学习默认配置其实就能启动ES 8.x它默认开启安全认证会自动生成密码。但很多教程会教你先改配置我建议做两处修改# 集群名称同一个集群内必须一致 cluster.name: my-es-cluster # 节点名称 node.name: node-1 # 数据目录和日志目录建议单独指定避免解压目录被清掉 path.data: D:/es-data path.logs: D:/es-logs # 只允许本机访问本地学习足够安全 network.host: 127.0.0.1 http.port: 9200 # 8.x默认开启安全如果只是本地学习想省事可以先关掉 xpack.security.enabled: false如果你用的是ES 8.x并关闭了安全认证启动后直接访问 http://localhost:9200 就能看到JSON响应。如果保持默认开启安全认证首次启动会在终端里输出一个超级用户elastic的初始密码并且Kibana登录时需要用到千万别把那个窗口直接关了。另外再提一件事ES安装目录下不要有空格否则后续Kibana连接和脚本执行都会出现找不到路径的诡异问题。2.3 启动Windows下的启动方式与日志排查Windows下启动很简单进入bin目录双击 elasticsearch.bat或者在CMD里执行cd D:\elasticsearch-8.13.0\bin elasticsearch.bat启动成功后会看到类似这样的日志[2025-01-10T10:00:00,000][INFO ][o.e.n.Node] [node-1] started [2025-01-10T10:00:00,000][INFO ][o.e.l.Lifecycle] [node-1] Elasticsearch started那如果启动失败呢最常见的两种情况一是端口被占用了尤其是9200和9300被其他程序占着二是堆内存配置不对。ES在启动时会根据系统内存自动设置JVM堆大小但默认的JVM参数在很多机器上会导致启动闪退。如果你看到Could not reserve enough space for 2097152000 bytes这种报错基本就是内存分配问题。要去config/jvm.options里调整# 堆大小通常设为物理内存的一半但不要超过32G -Xms4g -Xmx4g重点提醒ES 8.x默认会在启动时把 bootstrap checks 跑一遍。Windows下如果看到max file size checks之类的提示大多数情况下只是警告不影响启动。但如果你用了服务方式注册elasticsearch-service.bat install实际启动失败时的错误日志不会直接打到CMD里要去path.logs配置的目录下翻elasticsearch.log或者用 -f 参数在前台运行观察详细输出。2.4 安装Kibana并成功关联ESKibana是ES的可视化管理工具排查数据、写查询、看监控都不用命令行敲得手酸。Kibana的版本必须和ES保持严格一致ES是8.13.0Kibana必须也是8.13.0差一个小版本都可能连不上。下载Kibana压缩包解压后改config/kibana.yml# 本机Kibana监听端口 server.port: 5601 server.host: localhost # ES连接地址 elasticsearch.host: http://localhost:9200在Windows下启动Kibana也很简单进入bin目录执行 kibana.bat。启动需要等一会儿看到Kibana started就说明成功了。如果ES关闭了安全认证Kibana启动后直接访问 http://localhost:5601 就能进入。如果ES开启了安全认证你需要在kibana.yml里再配置elasticsearch.username: kibana_system elasticsearch.password: 你设置的密码或者用初始elastic超级账户密码配置本地学习图省事可以直接用elastic账户。Kibana里面我最常用的功能就是Dev Tools它内置了一个Console面板可以直接写ES的REST API比外部curl工具好用太多后面所有操作示例我默认都是在Dev Tools里执行的。3. 上手操作索引、文档与查询的第一课跑起来之后才是真正开始认识ES的阶段。这一章我会按照建索引-写数据-查数据的顺序来一遍每一步都是实际工作中每天都在重复的操作。3.1 索引设计与映射别急着往里写数据很多人上来就直接往ES里POST一条JSON数据发现也能成功。这是因为ES默认开启了动态映射dynamic mapping它会根据你第一条数据的字段值自动推断类型。比如你传了一个price: 199它就给你映射成long类型传2025-01-01它又给你映射成date类型。这个特性在小数据量demo时很爽但真实业务里非常危险。因为一旦映射定下来后续想改字段类型只能重建索引。而且动态映射的分词器选择往往不是最优的中文文本字段默认用的是标准分词器查中文会按单字拆效果很差。所以我建议写数据之前先手动创建索引并定义好映射。举个业务场景——商品搜索PUT /product_index { settings: { number_of_shards: 3, number_of_replicas: 1 }, mappings: { properties: { product_name: { type: text, analyzer: ik_max_word, search_analyzer: ik_smart }, category_id: { type: keyword }, price: { type: double }, stock: { type: integer }, sale_count: { type: integer }, status: { type: keyword }, created_at: { type: date, format: yyyy-MM-dd HH:mm:ss } } } }这里的IK分词器需要自己额外安装对应IK分词器插件适用于中文场景如果不装可以先改用ES内置的standard或whitespace分析器跑个demo。关键字段类型就几个常用的字段类型适用场景说明text全文搜索字段如标题、描述会被分词不能直接参与聚合排序需加fielddata或keyword子字段keyword精确匹配、过滤、聚合如状态、ID不分词整体作为一个词项存储integer/long/double数值字段支持范围查询、排序、聚合date时间字段支持日期范围查询和date_histogram聚合boolean布尔开关过滤常用object/nested复杂嵌套结构nested用于数组对象query时用nested语法一个很常见的坑是你把一个text字段直接拿来聚合会报错Fielddata is disabled on text fields by default。解决办法就是在mapping里加一个keyword子字段product_name: { type: text, fields: { keyword: { type: keyword, ignore_above: 256 } } }这样你可以用product_name做全文搜索用product_name.keyword做精确聚合和排序。3.2 文档的增删改查curl和Kibana Dev Tools都能干创建索引之后往里面写数据就叫索引文档index document。最简单的写入PUT /product_index/_doc/1001 { product_name: 红色毛衣女新款, category_id: clothes_001, price: 199.00, stock: 500, sale_count: 3200, status: on, created_at: 2025-01-10 12:00:00 }这里PUT后面跟的1001是文档的_id。如果不指定_id用POST请求ES会自动生成一个随机IDPOST /product_index/_doc { product_name: 蓝色牛仔裤男, category_id: clothes_002, price: 129.00, stock: 1000, sale_count: 1800, status: on, created_at: 2025-01-10 12:00:00 }查询文档用GETGET /product_index/_doc/1001更新文档有两种方式一种是完全覆盖用PUT加_id一种是局部更新用_update通过doc字段传递要改的部分POST /product_index/_update/1001 { doc: { price: 189.00, stock: 480 } }删除文档DELETE /product_index/_doc/1001如果你在Kibana Dev Tools里执行会发现每个操作都返回一堆JSON里面有result字段created表示新增updated表示修改deleted表示删除。但实际业务里单条增删改根本不够用更多是批量写入。ES的_bulk接口一次性能提交大量操作写入性能比一条条调高一个数量级POST /_bulk {index: {_index: product_index, _id: 2001}} {product_name: 黑色羽绒服, category_id: clothes_003, price: 699.00, stock: 200} {index: {_index: product_index, _id: 2002}} {product_name: 灰色卫衣男, category_id: clothes_004, price: 159.00, stock: 800} {delete: {_index: product_index, _id: 1001}}批量接口每一行都是一条操作指令交替出现指令行和数据行。这个格式有点怪但你用Logstash或ES的SDK时它们内部就是按这个格式组装请求的。3.3 查询从入门到组合match、term、bool和range查询是ES最核心的使用场景。如果只会用全文搜索那就等于没入门ES。实际工作中你要处理的大部分都是组合查询、过滤、排序、分页。最基本的全文搜索用match查询。它会对查询条件做分词然后去倒排索引里匹配GET /product_index/_search { query: { match: { product_name: 红色毛衣 } } }精确匹配则用term查询它不会分词通常用于keyword字段或数值、日期字段GET /product_index/_search { query: { term: { status: on } } }真实场景很少只有一个条件。电商搜索经常是关键词类目价格区间状态的组合这时候用bool查询GET /product_index/_search { query: { bool: { must: [ { match: { product_name: 毛衣 } } ], filter: [ { term: { category_id: clothes_001 } }, { range: { price: { gte: 100, lte: 300 } } }, { term: { status: on } } ] } }, sort: [ { sale_count: { order: desc } } ], from: 0, size: 20 }请注意这里我把价格区间、状态过滤放在了filter而不是must里。这是ES一个重要的性能优化点filter只做条件过滤不参与相关性打分而且结果会被ES缓存所以同一个filter条件在后续查询中被反复使用时性能提升非常明显。match参与打分会影响排序结果。你把不该打分的条件放must里不但查询变慢还会把相关性分数搞乱。如果你需要至少满足其中几个条件可以用should。但注意should在bool里的语义很关键当bool里同时有must和should时should会被当成加分项而不是或条件也就是说只要must满足即使should都不满足也会返回结果。如果只有should没有must它才等同于OR。这个特性我踩过好几次很多人也在这里翻车。分页和深度分页又是另一个坑。ES默认分页用from和size但如果你要从第10000条之后取数据ES会警告你the maximum value for from is 10000。因为在分布式环境下深度分页需要每个分片都取出fromsize条数据然后在协调节点聚合成大列表代价极高。真正的解决方案是用search_after做游标翻页它基于上一页最后一条数据的排序值来定位下一页适合滚动加载更多这种场景。还有一种scroll接口适合一次性导出大量数据做批处理但新版本里已经逐渐边缘化不推荐作为实时查询方案。4. 进阶能力聚合分析与数据恢复实战搜索只是ES一半的能力另一半是聚合分析。标题是从认识到掌握那这块就绕不开。另外搜索热词里还有elasticsearch恢复数据这几乎是生产环境一定会遇到的硬需求我也放在这一章。4.1 聚合分析从统计到分组ES的聚合aggregation分为三类指标聚合metric、桶聚合bucket、管道聚合pipeline。指标聚合最简单就是你熟悉的统计函数sum、avg、min、max、count、cardinality等。比如统计所有在售商品的平均价格和总库存GET /product_index/_search { size: 0, aggs: { avg_price: { avg: { field: price } }, total_stock: { sum: { field: stock } } } }size: 0 表示不返回具体文档只看聚合结果这是写聚合查询时的惯例。桶聚合就是GROUP BY最常用的是terms聚合和date_histogram分组。比如按类目统计商品数GET /product_index/_search { size: 0, aggs: { category_count: { terms: { field: category_id.keyword, size: 10 } } } }注意这里用了category_id.keyword就是因为之前说过的影响——text字段不能直接聚合。如果你mapping里没有设置keyword子字段这一条查询就会报错。date_histogram的典型场景是按天、按小时统计日志量或订单量GET /product_index/_search { size: 0, aggs: { sales_over_time: { date_histogram: { field: created_at, calendar_interval: day } } } }聚合最常用的还有子聚合sub-aggregation也就是先分组再对组内做统计。比如按类目分组再统计每个类目的平均价格GET /product_index/_search { size: 0, aggs: { category_count: { terms: { field: category_id.keyword }, aggs: { avg_price_in_category: { avg: { field: price } } } } } }真实项目中分组组内TopN也是高频需求。比如找出每个类目里卖得最好的前3个商品就可以在桶聚合里嵌套top_hits子聚合。聚合用起来不难难的是理解es的执行模型每个分片先做本地聚合协调节点再合并结果。数据量大时terms聚合的精确度受限于shard_size参数这又是一个调优场景。4.2 数据备份快照仓库配置说到恢复数据很多人第一反应是从备份恢复或者是把ES里的数据导出再导入。先说快照。ES的快照机制是把当前索引的数据和元数据完整存到一个共享仓库里仓库可以是本地文件系统、NFS、S3、HDFS等。生产环境建议用S3或NFS本地开发可以先注册一个本地路径仓库。注册仓库的APIPUT /_snapshot/my_backup_repo { type: fs, settings: { location: D:/es-backup, compress: true, max_snapshot_bytes_per_sec: 50mb, max_restore_bytes_per_sec: 50mb } }如果是分布式集群要注意这个location路径必须在所有节点都能访问到的共享存储上否则即使注册成功实际备份时也会因为某节点写不进去而失败。创建快照PUT /_snapshot/my_backup_repo/snapshot_20250110 { indices: product_index,order_index, ignore_unavailable: true, include_global_state: false }这里的include_global_state我建议设成false有些集群配置和模板不需要跟着快照走跨环境恢复时会省掉很多麻烦。查看快照状态GET /_snapshot/my_backup_repo/snapshot_20250110/_status查看快照列表GET /_snapshot/_all4.3 数据恢复实操两种常见场景场景一误删索引或索引损坏需要从快照恢复。POST /_snapshot/my_backup_repo/snapshot_20250110/_restore { indices: product_index, rename_pattern: product_index, rename_replacement: product_index_restored, ignore_unavailable: true, include_global_state: false }这里有个非常关键的区别ES的快照恢复不是覆盖式恢复而是创建式恢复。如果你要恢复的product_index已经存在并且里面还有数据恢复会失败报错类似index product_index already exists。所以生产上做恢复之前要么先关闭或删除原索引要么像上面这样用rename_pattern加rename_replacement把恢复出来的索引换个名字。恢复完成后如果你确认数据没问题再通过reindex把数据从product_index_restored迁移到原索引或者干脆切换别名这才是安全的操作路径。场景二A集群的数据要迁移到B集群比如换机器、跨容器环境。最实用的办法有两种第一种是快照仓库在两个集群里都注册同一个存储然后在新集群直接恢复不需要额外复制数据。第二种是用reindex从一个集群的远端索引拉数据到新集群。新集群执行PUT /_reindex { source: { remote: { host: http://旧集群IP:9200, username: elastic, password: xxx }, index: product_index, size: 5000, slice: { id: 0, max: 5 } }, dest: { index: product_index_new } }需要注意reindex从远端拉数据走的是HTTP数据量大的时候非常慢建议配合多slice并发。我在实际迁移中用过6个slice把约2000万条数据从旧环境迁到新环境耗时大约40分钟比单线程快很多倍。注意reindex时默认不会同步原索引的mapping和settings目标索引如果没有提前创建ES会按动态映射生成。所以我通常的做法是先把原索引的mapping和settings用GET /product_index/_mapping导出来手动创建目标索引后再执行reindex。5. 避不开的选择题Elasticsearch还是OpenSearch搜索热词里出现opensearch和elasticsearch不是偶然。很多人下载ES时会在官网看到OpenSearch的入口或者被公司内部告知新项目统一用OpenSearch。这不是一个版本小差异而是两个走上了不同路线的同源产品。5.1 两者的关系与差异OpenSearch是Elasticsearch 7.10版本的分支后来由社区继续发展并形成了独立的版本号和路线图。两者在核心API上有大量兼容的地方索引、文档、查询、聚合的语法基本一致很多现有ES 7.X脚本可以在OpenSearch上直接运行。但分叉之后差异点会逐渐增多。对比项ElasticsearchOpenSearch版本路线7.x、8.x快速迭代2.x、3.x独立演进安全认证基础版内嵌免费版也附带安全插件机器学习/向量检索官方功能持续更新靠插件或替代方案许可模式Elastic License / SSPLApache 2.0社区生态教程多、工具链全更新更快、有云厂商背书对于普通使用者来说最直观的感受是两者日常操作几乎一样但ES的教程和StackOverflow上的答案明显更多遇到问题更容易搜到解决方案OpenSearch则胜在完全开源、无许可顾虑而且它的OpenSearch Dashboards原Kibana分支默认带的安全功能更丰富。5.2 如何根据项目情况做选型我自己的判断标准是如果是个人学习或中小企业自建搜索且没有明确的商业授权预算选哪个都行OpenSearch在纯开源合规性上更有优势如果团队已经基于ES生态积累了代码、插件、监控方案或者需要用到ES独有的新特性比如更完善的向量搜索、ELSER相关性模型等继续用ES更顺手。如果公司对开源License比较敏感或者法务明确要求不能用SSPL/Elastic License那就直接选OpenSearch。反过来如果你需要商业支持、完善的官方文档和全托管服务Elastic官方云产品Elogtics Cloud更省心。一个务实的建议不要把选型问题想得太重。你的业务代码只要不深度依赖某个产品的私有API基于两者兼容的那一大块语法未来即便需要迁移成本也可控。5.3 迁移时需要注意的坑如果你决定从Elasticsearch迁到OpenSearch或者反过来有几个坑必须提前知道映射兼容性不是100%。ES 8.x引入了一些新的字段类型或参数如flattened、常量和某些分析特性在OpenSearch里可能不支持迁移前最好把全量索引的mapping导出来跑一遍兼容性校验。安全配置差异。ES 8.x把xpack.security变成了默认开启OpenSearch则是用自带的Security Plugin。两边认证方式、角色模型、用户管理API都不同。如果你原来直接用ES的安全API生成令牌迁移到OpenSearch必须重写这部分代码。监控和使用习惯迁移。Kibana切换到OpenSearch Dashboards后很多插件、图表控件不通用。比如Kibana的APM功能在OpenSearch里对应的是Data Prepper配置方式完全不同。团队如果已经熟练使用Kibana的可视化仪表盘迁移成本要算进项目工期里。6. 高频问题排查实录很多东西你以为知道但只有出问题时才算真明白。这一章是我从Windows本地开发到生产环境运维中踩过的坑也是搜索热词里那些启动失败、恢复数据、健康异常背后的真实问题总结。6.1 启动失败JDK、堆内存、端口占用ES启动失败的原因里排行前三的如下。JDK版本不符。报错关键信息一般是Java version mismatch或Support for Java 8 was removed。处理方法装JDK 17确认JAVA_HOME环境变量指向它重开CMD再启动。内存不够。Windows开发机如果只有8G内存ES默认堆大小在代码里配置的是按物理内存的一半上限自动算但很多情况下会分配出2G~4G堆再加上Kibana、其它IDE机器直接就卡死了。处理办法是在jvm.options里显式调小-Xms1g -Xmx1g端口占用。报错常见信息是Address already in use。Windows下用 netstat -ano | findstr 9200 找出占用PID然后任务管理器结束对应进程也要注意9300端口节点间通信被占用的情况解决方式同理。还有一个新手不太容易发现的坑你在CMD里启动ES然后按CtrlC关闭其实ES可能没有完全退出后台还有一个Java进程占着端口。这种情况下用tasklist找到java.exe全部结束再重启。6.2 集群健康状态yellow/red的排查集群健康状态是ES运维里最基本的体检指标。GET /_cluster/health 返回的status字段状态含义常见原因green所有主分片和副本分片都正常健康yellow主分片全部可用有副本分片未分配单节点集群、磁盘空间不足、副本数配置过高red至少一个主分片未分配节点宕机导致数据丢失、磁盘损坏、分片分配异常单节点集群出现yellow非常正常因为副本没地方放。但这不代表集群故障只需要保持副本为1、且节点数为1时yellow其实就是这个部署形态的健康状态。真正要警觉的是red。排查步骤一般是# 查看哪块索引和分片出问题 GET /_cat/indices?vhealthred # 查看未分配分片的原因 GET /_cluster/allocation/explain?pretty_allocation/explain是排查利器。它会告诉你具体某个分片为什么没分配常见的reason有reason问题解法NODE_LEFT持有该分片的节点离开集群让节点重新加入或手动重新分配INDEX_REOPENED索引刚被重开主动分配分片SHARD_LIMIT_GROUP分片数量超过单节点限制调大cluster.routing.allocation.total_shards_per_nodeREMAINING_NODES没有节点能满足分配规则比如磁盘白名单检查磁盘和分配策略很多red问题并不代表数据已经彻底丢失。如果只是分片未分配还可以重试分配POST /_cluster/reroute?retry_failedtrue这个命令让ES重新做分片分配尝试。偶尔能救回来但如果你反复retry也回不来多半是数据真的脏了或副本都没有那就得从快照恢复。这正是上一章快照用处的意义所在。6.3 查询慢、写入慢的调整思路ES查询变慢了是工单里最常见的诉求但90%的情况不是ES不行而是你让它干了太重的事。查询慢的排查思路按优先级来第一看是否用对查询类型。该用filter却用了must常见问题text字段上做了大量term聚合、没有用filter缓存、结果集过大导致fetch阶段耗时。第二看是否需要分页。深度分页非常耗资源如果用from/ size翻到几万条性能必然会退化。改成search_after或改用滚动型场景能保住尾巴的体验。第三看排序字段。对text字段或分词字段做排序默认不允许要么用keyword子字段要么在mapping设计时考虑将排序字段独立出来。写入慢的排查思路主要是这几个角度bulk批量的大小是否合理。每批5000条到10000条比较常见太少了请求次数多太多了单次请求内存压力大。refresh_interval的设置。默认每秒自动刷新意味着每秒都会产生一次新段。如果做批量导入可以临时调大到30s甚至关闭导入完再调回来。副本数的影响。写入时会往主分片和副本分片同时写如果写入速度瓶颈明显可以在批量导入前把副本临时设为0写完后恢复。这是一个偷懒但很有效的调优手段。# 写入前临时修改 PUT /product_index/_settings { index: { refresh_interval: 30s, number_of_replicas: 0 } } # 导入完成后恢复 PUT /product_index/_settings { index: { refresh_interval: 1s, number_of_replicas: 1 } }注意这个操作只适合在你对数据安全和集群可用性有把握时使用。生产环境如果直接清零副本一旦节点崩溃就会丢数据谨慎再谨慎。6.4 磁盘水位线与自动只读这个问题在真实环境太常见了突然发现ES写入报错错误提示是blocked by: [FORBIDDEN/12/index read-only / allow delete (api)]一看集群状态还是yellow/red的混合其实根本原因常常是磁盘不够了。ES有磁盘水位线机制当磁盘使用率超过某些阈值时会自动做限制保护水位线默认值触发行为cluster.routing.allocation.disk.watermark.low85%不再向该节点分配新的分片cluster.routing.allocation.disk.watermark.high90%尝试把分片迁移到其他节点cluster.routing.allocation.disk.watermark.flood_stage95%索引变为只读强制保护集群不被打挂当触发flood_stage时ES会把相关索引设置成只读。这个机制很安全但它的副作用也很坑你把磁盘清理出空间之后如果索引仍然是只读状态写入会一直失败。此时需要手动恢复PUT /product_index/_settings { index.blocks.read_only_allow_delete: null }如果你有大量索引都触发了只读可以用通配符PUT /_all/_settings { index.blocks.read_only_allow_delete: null }但这里要特别注意_all在集群级影响很大生产环境请谨慎使用最好只针对确实需要恢复写入的索引操作。在磁盘水位问题上我的体会是与其等触发再被动处理不如一开始就把监控做好让磁盘使用率保持在70%以下。ES自带的磁盘监控曲线在Kibana Stack Monitoring里就有不要省那几步配置的时间。一点个人经验从最早在Windows上解压ES玩一玩到后来在Linux生产环境搭三节点集群这中间走了不少弯路但ES带给我的收益非常大。它把我从用MySQL笨办法做搜索和统计的困局里解放出来让我面对几亿条日志、APP搜索自动补全、业务报表实时聚合这类需求时心里有底。如果要给刚开始接触ES的人一个最实在的建议那就是不要只停留在跑起来和能查到数据这一步。花点时间把倒排索引、分片副本、mapping设计这几个基础概念吃透然后用实际业务数据做一次从索引设计、写入、查询到聚合、快照备份、恢复演练的完整流程。这一套走完ES就算真正上手了。我自己后来所有生产环境的行为规范几乎都可以追溯到刚学ES时踩过的那些坑索引要先设计mapping再写数据、批量操作一定要走bulk、磁盘要留够余量、快照要定期演练恢复流程、备份不是备份了就行而是能恢复才算数。上面的内容你在官方文档里都能查到但把顺序和坑提前告诉你能省下不少自己摸索的时间。如果还有什么ES相关的具体问题欢迎在评论区留言我看到后会尽量回复。