用 where('title', 'like', '%'.$keyword.'%') 替代 whereLike，先 trim() 过滤空格及特殊字符，并在入库时统一处理格式；关联查询需用 whereHas 或闭包；全文索引需手动建索引并用 Db::query 执行 MATCH AGAINST；严格参数绑定防注入；分页避免 count 性能瓶颈。
ThinkPHP 6 的 whereLike 怎么写才不漏数据
直接说结论：用 whereLike 做模糊搜索时，默认是前后加 %，但空格、中文、特殊字符容易导致匹配失败。比如用户搜“苹果手机”，你查 title 字段，如果数据库里存的是“苹果 手机”（中间有空格）或“iPhone手机”，whereLike('title', '苹果手机') 就可能查不到。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 手动拼接
%更可控：where('title', 'like', '%'.$keyword.'%')，尤其当$keyword来自用户输入时，先trim()再过滤空字符 - 中文分词或空格问题常见于标题、简介类字段，建议在入库时统一处理（如替换全角空格为半角、去除多余空白），而不是全靠查询兜底
-
whereLike在关联查询中可能被忽略——它只作用于主表，连表后的子表字段得用whereHas或闭包with配合where
MySQL 全文索引 + ThinkPHP match against 怎么启用
想搜得快、支持自然语言（比如“苹果”也能匹配“iPhone”“MacBook”），就得用 MySQL 的全文索引，不是靠 like 硬扫。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 建表时给字段加全文索引：
ALTER TABLE `goods` ADD FULLTEXT(title, description)；注意 MyISAM 和 InnoDB 对全文索引的支持差异，TP6 默认用 InnoDB，需 MySQL ≥ 5.6 - TP6 不内置
MATCH ... AGAINST封装，得手写原生查询：Db::query("SELECT * FROM goods WHERE MATCH(title, description) AGAINST(? IN NATURAL LANGUAGE MODE)", [$keyword]) - 关键词长度限制：MySQL 默认忽略 ≤ 4 字符的词（如“i”“to”），可通过修改
ft_min_word_len并重建索引解决，但线上改需谨慎 - 不支持中文分词——这是最大坑。直接搜“智能手机”不会拆成“智能”“手机”，得配合第三方扩展（如 coreseek/sphinx）或换 ElasticSearch
ThinkPHP 搜索参数怎么安全传进查询
用户搜的内容不能直接拼 SQL，否则 ' or 1=1 -- 这种就穿了。TP6 的查询构造器默认防注入，但一不小心绕过去也很容易。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 永远用参数绑定，别拼字符串：
where('title', 'like', '%'.$keyword.'%')是安全的；但whereRaw("title like '%{$keyword}%'")就危险 - 多个搜索条件组合时，避免写死逻辑，用数组动态构建：
$where = []; if ($keyword) $where[] = ['title', 'like', '%'.$keyword.'%']; if ($cate_id) $where[] = ['cate_id', '=', $cate_id]; Db::table('goods')->where($where)->select(); - 前端传来的
order、field类参数必须白名单校验，比如排序字段只允许['id', 'price', 'create_time']，否则order=updatexml(1,concat(0x7e,(select user()),0x7e),1)就能报错出库名
搜索结果分页时 count() 为什么越来越慢
用 paginate() 是方便，但当数据量上百万、又带模糊条件时，count(*) 本身就会全表扫描，比查数据还慢。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 确认是否真需要精确总数：后台管理可保留；C端列表建议用“下一页”代替页码，或显示“约 200+ 条结果”
- 给模糊查询字段加普通索引没用，
LIKE '%xxx'无法走索引；只有LIKE 'xxx%'才行，所以前缀搜索（如商品编号、用户名）可考虑用whereBetween或范围索引优化 - TP6 的
paginate()支持传入预计算的总数：paginate(15, false, ['total' => $estimatedCount])，配合缓存或采样估算更实用
全文检索不是加个 match 就完事，中文、性能、安全三块最容易掉链子。尤其是分词和索引维护，上线后几乎没法热更新，得在设计阶段就想清楚边界。
