yii框架搜索需分条件筛选与全文检索：用activerecord的andfilterwhere等安全构建查询，避免like模糊匹配性能问题；超10万行或需分词/权重时，必须集成elasticsearch等专业引擎。
Yii 框架本身不内置全文检索引擎，搜索功能必须拆解为「条件筛选」和「外部全文检索集成」两部分来实现；直接用 ActiveRecord::find()->where() 做模糊匹配（如 LIKE '%关键词%'）在数据量稍大时就会慢、不准、不支持分词——这不是写法问题，是技术边界问题。
怎么用 ActiveRecord 实现可靠的基础条件筛选
绝大多数业务搜索其实是多字段组合过滤（比如“状态=启用 + 创建时间在7天内 + 标题含XX”），不是全文检索。这时应避免手写 SQL 或拼 WHERE 字符串，而是用 Yii 的查询构建器做链式条件组装：
-
andFilterWhere()是关键：它会自动跳过空值或null参数，防止生成WHERE title = ''这类无效条件 - 日期范围要用
andFilterWhere(['between', 'created_at', $start, $end])，别用字符串拼接，否则时区或格式错就查不到数据 - 枚举字段（如 status）建议用
in而非多个=，例如andFilterWhere(['status' => [1, 2]]) - 如果字段加了数据库索引但查询仍慢，检查是否用了函数导致索引失效——比如
LOWER(title)匹配，应改用数据库层面的大小写不敏感排序规则（如 MySQL 的utf8mb4_unicode_ci）
// 示例：后台列表搜索逻辑 $query = Article::find(); $query->andFilterWhere(['status' => $this->status]); $query->andFilterWhere(['between', 'created_at', $this->start_date, $this->end_date]); $query->andFilterWhere(['like', 'title', $this->keyword]); $query->andFilterWhere(['like', 'content', $this->keyword, false]); // false 表示不加 % 前后缀
什么时候必须上 Elasticsearch / Sphinx，而不是 LIKE
当出现以下任一情况，LIKE 就该停用了：
- 用户输入“苹果手机”，期望匹配到“iPhone 15 苹果官方旗舰店”——
LIKE只能靠前缀或整串匹配，无法分词、权重、同义词 - 搜索响应超过 800ms，且表数据 > 10 万行（InnoDB 即使有索引，
LIKE '%xxx%'也必走全表扫描） - 需要高亮关键词、拼写纠错、搜索建议（search-as-you-type）
- 涉及多表关联内容聚合搜索（如“查张三参与的所有订单及对应商品名”）
Yii 本身不绑定任何搜索引擎，但可通过扩展接入。推荐方案：yii2-elasticsearch（官方维护）对接 Elasticsearch 7.x+，或用 yii2-sphinx 对接 Sphinx/ThinkingSphinx。注意：Elasticsearch 需单独部署服务，不能仅靠 PHP 扩展完事。
如何让搜索表单参数安全透传到查询逻辑
常见错误是把 $_GET 直接塞进 where()，既危险又难维护。正确做法是：
- 定义一个继承
Model的搜索类（如ArticleSearch），在其中声明公共属性（public $keyword; public $status;）并配置rules()做类型校验 - 在控制器中调用
$searchModel->load(Yii::$app->request->get())，它会自动过滤未声明属性、执行验证规则 - 避免在搜索类里写复杂查询逻辑——只做参数接收和基础转换（如把日期字符串转为时间戳），查询构建仍放在
search()方法里返回ActiveQuery - 如果前端传了非法字段（如
?sort=id;DROP TABLE users），load()不会赋值，比手动Yii::$app->request->get('xxx')安全得多
为什么不要在搜索里滥用 join 和 select *
搜索接口最容易因关联查询拖垮性能。典型陷阱：
- 为了显示“作者名”，对
User表做join，结果一条搜索返回 100 条文章，就触发 100 次 author 关联查询（N+1）——应改用with('author')预加载，或直接冗余 author_name 字段到文章表 -
select *查出所有字段（包括大文本、二进制 blob），网络传输和内存开销陡增——明确写select(['id', 'title', 'summary']) - 在搜索中
groupBy或having而没加索引字段，MySQL 可能放弃使用索引，改用临时表+文件排序 - 分页用
limit 10000, 20时，MySQL 仍要扫描前 1 万行——大数据量分页应改用游标（cursor-based pagination），以最后一条 ID 为起点
全文检索不是加个 LIKE 就算做完的事。真正卡住进度的，往往是没想清楚「这到底是精确筛选，还是语义召回」——前者交给数据库索引和 ActiveRecord，后者必须交给专业搜索引擎，中间没有平滑过渡的捷径。
