结论：小数据量用LIKE，大数据量或需语义搜索时必须用FULLTEXT。LIKE部署简单但全表扫描性能差；FULLTEXT基于倒排索引，支持相关性排序、分词与停用词处理，效率和准确性显著更高。
PHP搜索功能该用 LIKE 还是 FULLTEXT？
直接说结论：小数据量（LIKE 最快上手；但只要涉及中文分词、多字段权重、相关性排序，FULLTEXT（配合 MySQL 5.7+ 或 MariaDB）才是正解。别被“全文索引要建表”吓住——它不难，但跳过这步直接写 WHERE title LIKE '%关键词%'，后期数据一涨就卡死。
常见错误现象：LIKE '%关键词%' 在 title 字段查“苹果”，结果把“香蕉苹果汁”“青苹果派”全捞出来，但“苹果手机”反而漏了（因为字段里存的是“iPhone 苹果手机”且空格/标点干扰）；而没加 FULLTEXT 索引时，MATCH(title, content) AGAINST('苹果') 会直接报错 ERROR 1191: Can't find FULLTEXT index matching the column list。
- MySQL 中启用
FULLTEXT只需一句：ALTER TABLE articles ADD FULLTEXT(title, content); - 中文需额外处理：MySQL 原生
FULLTEXT对中文支持弱，要么用ngram插件（5.7.6+），配置ft_parser=ngram并设ngram_token_size=2；要么前置分词（如用scws或jieba-php）后存入独立 keyword 字段再建索引 -
LIKE搜索必须加ESCAPE防注入：用户搜%admin%会被当通配符，得先str_replace(['%', '_'], ['\%', '\_'], $keyword)再拼进 SQL
如何安全接收并过滤 PHP 搜索参数？
用户输的从来不是“关键词”，而是潜在的 SQL 注入、XSS、空格乱码、超长字符串。别信 $_GET['q'] 是干净的。
典型翻车场景：前端传 ?q=<script>alert(1)</script>，后端没过滤就直接 echo $_GET['q'] 渲染到页面；或者传 ?q=1' OR '1'='1，用 mysql_query("SELECT * FROM users WHERE name LIKE '%$q%'") 直接崩库。
立即学习“PHP免费学习笔记（深入）”；
- 强制用
filter_input()：例如$q = filter_input(INPUT_GET, 'q', FILTER_SANITIZE_STRING);，它比trim(strip_tags($_GET['q']))更可靠，自动删 null 字节和危险字符 - 数据库查询必须用预处理：
$stmt = $pdo->prepare("SELECT * FROM posts WHERE MATCH(title,content) AGAINST(? IN NATURAL LANGUAGE MODE)"); $stmt->execute([$q]); - 长度限制不能只在前端做：
if (strlen($q) > 50) { die('关键词太长'); }，防止恶意提交超长字符串拖慢 DB
为什么搜索结果总缺页、重复或排序错？
分页和排序不是加个 LIMIT 就完事。特别是用 FULLTEXT 时，ORDER BY MATCH() DESC 必须和 WHERE MATCH() 同字段，否则 MySQL 会忽略索引走全表扫描。
容易被忽略的坑：SELECT id,title FROM articles WHERE MATCH(title,content) AGAINST('php' IN NATURAL LANGUAGE MODE) ORDER BY id DESC LIMIT 10 —— 这条看似正常，但 MySQL 无法利用 FULLTEXT 索引做排序，实际执行计划里 type 是 ALL，性能暴跌。
- 正确写法：排序字段必须出现在
MATCH()里，例如ORDER BY MATCH(title,content) DESC, created_at DESC - 分页慎用
LIMIT 10000,20：偏移量大时，MySQL 仍要扫描前 10020 行。改用游标分页：WHERE id ，把上一页最后的 <code>id当作下一页起点 - 去重靠
DISTINCT不够：如果同一条记录在 title 和 content 里都匹配“php”，MATCH()可能返回两次。加GROUP BY id或用子查询先取唯一 ID
PHP 搜索要不要自己写分词或上 Elasticsearch？
纯 PHP 写中文分词（比如用 mb_substr() 切字）基本是自找麻烦——没有词性识别、没有停用词、不支持同义词扩展，搜“iPhone”找不到“苹果手机”。但直接上 Elasticsearch 又太重，尤其小项目连运维资源都没有。
真实权衡点：如果搜索只是站内文章标题+摘要，且日活 FULLTEXT + ngram 足够；一旦要支持拼音搜索（搜“zhongguo”出“中国”）、地理位置筛选、实时增量更新，就得切 Elasticsearch。
- 轻量替代方案：用
MeiliSearch（Rust 写的，单二进制文件，HTTP API，PHP 用curl或meilisearch-phpSDK 调用） - 如果坚持 PHP 分词，别自己造轮子，用现成的
overtrue/pinyin处理拼音搜索，或hightman/xunsearch（国内老牌，支持中文，部署比 ES 简单） - 注意字符集：MySQL 表、连接、PHP 文件都必须统一为
utf8mb4，否则“?”这类 emoji 或生僻字一搜就空
搜索功能最复杂的部分往往不在代码里，而在数据清洗和用户预期管理——比如用户搜“免费教程”，你返回一堆“免费试看”的付费课程详情页，再快的算法也救不了体验。先想清楚“什么算匹配”，再决定用哪个工具。
