优先用前缀匹配（如“java%”）走索引，避免“%keyword%”全表扫描；中文/长文本改用FULLTEXT索引；高并发模糊搜索宜接入Elasticsearch，注意客户端与服务端版本兼容及正确关闭连接。
LIKE 查询在 Java 中怎么写才不拖垮数据库
直接拼 LIKE 很快，但查得越模糊越慢——尤其是 %keyword% 这种前后通配，MySQL 无法走索引，全表扫描一来，10 万行就明显卡顿。
常见错误是把用户输入原样塞进 PreparedStatement，比如：SELECT * FROM article WHERE title LIKE ?，然后传入 "%java%"。这本身没错，但没控制模糊范围，也没做前置过滤。
- 优先用前缀匹配：
title LIKE ?+"java%"，这样能命中 B+ 树索引 - 对中文或长文本搜索，避免
LIKE "%关键词%"，改用 MySQL 的FULLTEXT索引 +MATCH ... AGAINST - 加
LIMIT和合理分页，别让OFFSET越翻越慢（比如OFFSET 10000） - 字段加
COLLATE utf8mb4_unicode_ci避免大小写/重音敏感问题，否则like 'Java'可能漏掉java
Elasticsearch Java API 接入最简路径
不用 Spring Data Elasticsearch，直接上官方 RestHighLevelClient，三步就能发一个模糊搜请求，比搭全套框架快得多。
容易踩的坑是依赖版本和 ES 服务端不一致：比如用 elasticsearch-rest-high-level-client:7.17.0 连 ES 8.x 会报 406 Not Acceptable 或序列化失败；连 ES 6.x 则可能缺 source() 方法。
立即学习“Java免费学习笔记（深入）”；
- 客户端初始化必须指定
HttpHost，且端口是 HTTP 端口（默认9200），不是传输端口（9300） - 构建查询用
MatchQueryBuilder比WildcardQueryBuilder更稳，后者类似LIKE '%x%'，性能差还易误匹配 - 返回结果要显式调用
SearchResponse.getHits().getHits()，别漏掉.getHits()这一层 - 记得关 client：
client.close()，否则连接池耗尽后抛NoNodeAvailableException
LIKE 和 ES 搜索该选哪个场景
不是“ES 一定更好”，而是看数据量、更新频率和搜索精度要求。
比如后台管理查订单号，用 LIKE 'ORD2024%' 完全够用，加个索引毫秒响应；但要做“用户搜‘苹果手机’返回带 iPhone、MacBook、iOS 的结果”，LIKE 就彻底失效了。
- 数据量 LIKE + 索引优化
- 需同义词（如“笔记本”=“notebook”）、拼音搜索、相关度排序、高亮 → 必须 ES
- 频繁更新（每秒百次写入）又要求搜最新数据 → ES 的近实时（NRT）延迟（默认 1s）可能不满足，这时得权衡或调小
refresh_interval - ES 不适合做精确主键查询（比如
id = 123），这种仍该走数据库
从 LIKE 迁移到 ES 时最容易漏的三件事
迁移不是换一个查询语句，而是补全整个链路：数据同步、空值处理、错误降级。
很多人测通一个 match 查询就以为成了，上线后才发现搜索结果为空、中文分词乱码、或者 ES 挂了整个页面白屏。
- 没配中文分词器（如
ik_max_word），导致"全文搜索"被切成单字或不分词，搜“全文”找不到 - 数据库新增/修改数据后，没同步到 ES（靠监听 binlog 或业务层双写），造成搜索结果滞后甚至缺失
- 没设 fallback：ES 请求超时或 5xx 时，应自动切回
LIKE查询，而不是直接报错给用户
ES 的 mapping 定义、分词器配置、bulk 写入重试逻辑，这些不在 Java 代码里体现，但出问题时第一个背锅。
