如何实现同表同参数多字段模糊匹配的单查询分页搜索

你当前的三查询写法存在明显缺陷：三次独立数据库请求性能差、分页逻辑完全失效、重复数据无法自动去重，完全可以通过单查询实现需求，以下是两种可直接落地的实现方式：

方案1：最简JPQL实现（适合固定字段场景） #

直接在WHERE子句中用OR拼接所有需要匹配的模糊条件即可，一次查询就能返回所有任意字段匹配的结果，同时自动支持分页。
首先修正你原有SQL的语法错误（JPQL是面向实体的查询，不是面向表的原生SQL，别名需要统一定义），Repository层只需要保留一个方法：

// 注意：如果你的A实体对应a_table表，JPQL中直接写实体类名即可，不需要写原生表名
@Query("select x from A x where x.name like %:searchText% or x.number like %:searchText% or x.project like %:searchText%")
Page<A> globalSearch(@Param("searchText") String searchText, Pageable pageable);

调用时直接传入搜索关键词和分页参数即可，返回的Page<A>对象会自动包含总条数、总页数、当前页数据等所有分页信息，自动去重同一条多字段匹配的记录。
如果需要处理搜索关键词中的通配符特殊字符（比如%/_），可以在Service层提前转义：

// 转义特殊字符
String keyword = searchText.replace("%", "/%").replace("_", "/_");
// 调用查询时指定转义符即可，修改@Query内容如下
// @Query("select x from A x where x.name like %:searchText% escape '/' or x.number like %:searchText% escape '/' or x.project like %:searchText% escape '/'")

方案2：Specification动态查询（适合后续需要扩展匹配字段的场景） #

如果后续可能新增更多需要匹配的字段，不想每次都修改JPQL语句，可以用Spring Data JPA的Specification实现动态条件拼接，扩展性更强：

1. 首先让你的Repository接口继承JpaSpecificationExecutor<A>：

   public interface ZRepo extends JpaRepository<A, Long>, JpaSpecificationExecutor<A> {
       // 不需要再写三个独立的@Query方法
   }
   

2. 构造通用的多字段匹配查询条件：

   public Specification<A> buildGlobalSearchCondition(String searchText) {
       return (root, query, cb) -> {
           List<Predicate> matchPredicates = new ArrayList<>();
           // 需要匹配的字段统一在这里添加，后续扩展只需要新增一行代码
           matchPredicates.add(cb.like(root.get("name"), "%" + searchText + "%"));
           matchPredicates.add(cb.like(root.get("number"), "%" + searchText + "%"));
           matchPredicates.add(cb.like(root.get("project"), "%" + searchText + "%"));
           return cb.or(matchPredicates.toArray(new Predicate[0]));
       };
   }
   

3. 调用查询：

   Page<A> result = zRepo.findAll(buildGlobalSearchCondition(searchText), pageable);
   

原写法的问题说明 #

你之前写的三个独立查询方法存在几个明显错误和设计缺陷：

• 语法错误：JPQL中使用了原生SQL的select * from 表名写法，后两个查询没有定义x别名就直接使用，方法名存在拼写错误，直接运行会报SQL语法异常
• 性能浪费：三个查询会触发6次数据库交互（每个分页查询默认会触发一次count查询+一次数据查询），单查询只需要2次交互
• 分页完全失效：三个查询各自独立分页，最后返回的只是第三个查询的分页结果，前两个查询的匹配结果会被直接覆盖，根本无法拿到所有匹配数据
• 重复数据问题：如果一条数据同时匹配多个字段（比如你示例中project=910的记录同时匹配name和number字段），三个查询会重复返回同一条数据，手动去重+重新构造分页对象的逻辑非常冗余

大数据量优化提示 #

如果你的表数据量超过百万级，以上%关键词%的模糊匹配写法会导致数据库索引失效，查询性能下降，可以根据业务场景选择以下优化方案：

• 用MySQL自带的全文索引替代普通like查询
• 接入Elasticsearch/OpenSearch做专门的全文检索引擎

内容的提问来源于stack exchange，提问作者ari