Spring Data JPA中Containing、IsContaining、Contains、Like查询关键字有何区别

以下对比基于Spring Data JPA默认规则，针对Containing、IsContaining、Contains、Like四个常用模糊查询关键字展开：

1 核心功能差异 #

• Containing、IsContaining、Contains：三者为完全等价的同义词，功能完全一致。无需调用方手动添加通配符，框架会自动给传入的查询参数前后拼接%通配符，匹配字段值包含查询参数的所有记录。
• Like：框架不会自动拼接任何通配符，所有通配符规则完全由调用方在传参时自行定义，框架仅按照传入的参数值直接做like匹配。

2 生成SQL语句区别 #

以查询用户表user中name字段匹配参数nameVal = "张三"为例：

2.1 Containing/Contains/IsContaining #

对应方法定义：

List<User> findByNameContaining(String nameVal);
List<User> findByNameContains(String nameVal);
List<User> findByNameIsContaining(String nameVal);

三者生成的SQL完全一致：

select * from user where name like ?

实际绑定的参数值为%张三%，等价于匹配所有name字段包含“张三”的记录。

2.2 Like #

对应方法定义：

List<User> findByNameLike(String nameVal);

生成的SQL结构和上面一致，但是绑定的参数值完全由调用方传入的nameVal决定：

• 若传入nameVal = "张三%"，则绑定值为张三%，匹配name以“张三”开头的记录
• 若传入nameVal = "%张三"，则绑定值为%张三，匹配name以“张三”结尾的记录
• 若传入nameVal = "张_三"，则绑定值为张_三，匹配name为“张X三”（X为任意单个字符）的记录
• 若传入nameVal = "张三"没有任何通配符，则等价于name = "张三"的精确查询

3 适用业务场景 #

• Containing/Contains/IsContaining适用场景：
  • 业务需求为通用的“包含关键词”搜索，不需要自定义通配符位置
  • 不想在业务代码中手动拼接%通配符，减少冗余代码
  • 对模糊匹配规则没有特殊要求，仅需要判断字段是否包含指定内容的场景
• Like适用场景：
  • 需要自定义通配符位置的场景，比如前缀匹配、后缀匹配、单字符匹配等
  • 业务对模糊匹配规则有灵活要求，需要精确控制通配符的位置和数量
  • 需要适配复杂模糊匹配规则的定制化搜索场景

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