MySQL文本列高效搜索方案：解决WordPress自定义商品表检索慢问题

你当前性能瓶颈的核心是前后带通配符的LIKE查询无法利用普通B+树索引，每次检索都会触发全表扫描，哪怕给text字段加了普通索引也不会生效，可参考以下优化方案：

无需引入额外服务，仅需要调整索引和查询逻辑即可获得大幅性能提升：

• 首先确认products_search表使用支持全文索引的InnoDB/MyISAM引擎，给检索字段创建全文索引，执行SQL：
  CREATE FULLTEXT INDEX idx_ft_products_search_desc ON products_search(description);
• 替换原有的LIKE查询语句，使用MySQL原生全文检索语法：

SELECT product_id FROM products_search 
WHERE MATCH(description) AGAINST ('search_word_1 search_word_2' IN BOOLEAN MODE);

• 可根据业务需求调整MySQL的全文索引参数：比如英文场景可把ft_min_word_len默认值4下调到2，避免短词无法被检索到；你提前做的特殊字符转义处理也刚好适配全文索引的字符匹配规则。
• 该方案在单表数据量百万级以内时，检索性能比原LIKE查询高几十到上百倍。

WordPress自带搜索确实默认仅支持posts表，但可以通过钩子或者扩展插件适配自定义表：

• 代码实现：通过pre_get_posts钩子自定义WP_Query的搜索逻辑，把products_search表的检索结果关联到原生搜索返回结果中，复用WP原生搜索的排序、高亮等能力。
• 插件实现：使用SearchWP等搜索增强插件，这类插件支持自定义数据库表作为搜索源，你只需要在后台配置关联products_search表的对应字段、设置匹配权重，插件会自动生成专属索引、处理搜索请求，无需自行编写SQL逻辑。

如果你的商品数据量超过百万、或者需要更丰富的搜索能力（分词、拼写纠错、权重排序等），可以引入独立搜索引擎：

• 本地部署Elasticsearch/OpenSearch，每日批量更新CSV商品数据时，同步把检索需要的字段写入搜索引擎索引，用户搜索时直接请求搜索引擎获取匹配的商品ID，再关联主表返回完整数据。
• 也可以使用Elasticpress等WordPress ES对接插件，插件支持自定义索引源映射，可直接把products_search表的数据同步到ES索引中，自动处理搜索请求和结果返回，无需自行编写对接逻辑。

如果暂时不想调整现有检索逻辑，可以先做以下优化降低数据库压力：

• 把原查询语句的SELECT *改为仅查询你需要的product_id字段，减少无效IO消耗。
• 增加搜索缓存层：对高频搜索关键词的结果做缓存，可使用WordPress自带的对象缓存或者Redis缓存，缓存周期和你每日CSV更新的周期对齐，更新完成后统一清空缓存即可，可大幅降低重复搜索的数据库请求量。
• 限制单次搜索允许传入的关键词数量，比如最多支持3个关键词同时检索，避免过多OR条件拉长全表扫描的耗时。

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