Sphinx只存ID和倒排索引，需回查MySQL获取字段；Meilisearch默认存储完整文档字段，搜索直接返回。Sphinx查询慢主因是SQL关联、未配前缀搜索、max_matches过小；实时更新需用sql_query_post_index或RT index。
Sphinx 和 Meilisearch 都能显著提升 PHP 应用的全文检索性能，但适用场景完全不同：Sphinx 更适合已有 MySQL 架构、数据量大且对延迟敏感的 OLTP 类搜索（如商品列表、文章库）；Meilisearch 更适合新项目、需要开箱即用中文支持、实时性要求高、且不愿维护索引同步逻辑的场景。
为什么 Sphinx 的 query() 返回只有 ID，不带字段内容？
Sphinx 本身不存储原始文档字段（如 title、content），只存倒排索引和文档 ID。这是设计使然，不是 bug。
- 它通过
sql_query从 MySQL 读取数据建索引时，只提取用于分词和检索的字段，原始长文本不会写入索引文件 -
$sphinx->query('关键词', 'myindex')返回的matches数组里只有id和weight，没有业务字段 - 必须用这些 ID 回查 MySQL（例如
SELECT title, content FROM articles WHERE id IN (1024, 1025, ...)）才能拼出完整结果 - 如果漏掉这步回查，直接渲染
query()结果，页面就会显示空白或报错
Meilisearch 的 search() 为什么能直接返回字段？
Meilisearch 是文档型搜索引擎，索引中默认保留全部字段（除非显式配置 filterableAttributes 或 sortableAttributes 限制），所以一次查询就能拿到结构化结果。
- PHP SDK 调用
$client->index('movies')->search('盗梦空间')返回的数组包含title、overview等原始字段 - 无需额外查库，适合快速搭建 MVP 或前端直连搜索后端的架构
- 但代价是内存占用更高，索引体积比 Sphinx 大 2–3 倍（尤其含大量富文本时）
- 中文分词默认启用
chinese分词器，不用像 Sphinx 那样手动编译 coreseek 或配mmseg
Sphinx 查询慢的三个典型原因及对应调整
不是“加了 Sphinx 就一定快”，配置不当反而比 LIKE 还慢。
立即学习“PHP免费学习笔记（深入）”；
-
sql_query中用了JOIN或子查询：Sphinx indexer 会逐行执行该 SQL，复杂关联会极大拖慢建索引速度，也影响searchd内存使用；应改用宽表预计算，或在 MySQL 侧建物化视图 - 未设置
min_infix_len = 1却想支持模糊前缀搜索（如输入“搜”匹配“搜索引擎”）：默认只对完整词干匹配，需在 index 配置块中显式开启，并重建索引 -
SetLimits(0, 20, 1000)的第三个参数（max_matches）设得太小：当真实匹配数超限时，Sphinx 会截断结果并降权后续文档，导致第 500 条之后的高相关文档永远无法被翻页查到；生产环境建议设为 10000+ 并配合 MySQLLIMIT控制最终返回量
PHP 中同步更新 Sphinx 索引的两种可靠方式
不能依赖定时 indexer --rotate，否则有分钟级延迟。实时性要求高的业务必须主动触发。
- 用
mysql引擎 +sql_query_post_index：在 Sphinx 配置中定义一条 SQL，在每次增量索引完成后自动执行（如更新 MySQL 中的last_sphinx_update时间戳），再由应用轮询该时间戳决定是否重推 - 走
RT index（实时索引）：Sphinx 2.2+ 支持，PHP 可通过mysqli直连searchd的 MySQL 协议端口（默认 9306），用标准 INSERT/REPLACE 语句写入，无需重启服务；但 RT index 不支持所有分词配置，且内存消耗不可控，单机建议上限 500 万文档
真正难的从来不是“怎么装”或“怎么调 API”，而是判断哪部分数据值得进搜索索引、哪些字段必须回查、以及什么时候该放弃 Sphinx 改用 Meilisearch —— 比如你刚上线一个用户生成内容（UGC）社区，每天新增 10 万条短帖，且要支持拼音搜索、错别字容错、实时高亮，这时候硬套 Sphinx 反而增加运维负担。
