Tina 小姐姐1. 模糊查询的本质与挑战
第一次接触模糊查询需求时，我天真地以为这就是个简单的LIKE操作。直到线上系统因为"%关键词%"查询导致全表扫描，数据库CPU直接飙到100%，才意识到模糊匹配的水有多深。本质上，模糊查询是在不确定完整数据形态的情况下，通过部分特征进行信息检索，这种不确定性注定了它与传统精确查询完全不同的技术路线。
常规的B树索引在模糊查询场景下几乎失效，特别是前导通配符查询（如"%关键字"）。我曾测试过在百万级数据的用户表中查询"%技术%"这样的模式，即使字段有索引，MySQL依然选择了全表扫描，响应时间从毫秒级暴跌到秒级。这背后的原理是B树索引的排序特性决定了它只能高效支持前缀匹配（如"技术%"），而无法应对中间或后缀模糊匹配。
更棘手的是中文场景下的分词问题。英文单词天然有空格分隔，但中文需要额外处理。"数据库技术"如果被存储为连续字符串，查询"数据%"还能利用索引，但查询"%技术%"就无能为力。某次处理用户搜索日志时发现，超过60%的模糊查询都包含中文中间匹配，这直接促使我们开始研究专业搜索引擎方案。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 主流数据库的模糊查询能力评测
2.1 传统关系型数据库方案
MySQL的模糊查询性能可以说是"看天吃饭"。在我的压力测试中，对于1000万条的电商商品表，title LIKE '%手机%'的查询需要4.8秒完成，而title LIKE '苹果%'仅需0.02秒——240倍的性能差距。这里有个实战技巧：如果业务允许，尽量把通配符放在末尾，并确保字段有B树索引。
PostgreSQL在这方面提供了更多武器。除了基础的LIKE，其pg_trgm扩展引入了三元组索引，使得"%关键字%"这类查询也能利用索引。实测同样的查询，启用pg_trgm后响应时间从秒级降到毫秒级。但要注意，这种索引会显著增加存储开销（约原始数据的3倍），我曾经就因为没控制好索引大小导致存储空间暴增。
2.2 专业搜索引擎方案
当数据量超过千万级时，Elasticsearch就成了我的首选。其倒排索引机制天生为模糊查询优化，特别是配合ngram分词器使用时。在最近的一个电商项目中，我们将商品信息同步到ES集群，模糊查询响应时间稳定在50ms以内，即使面对"%新款智能手机%"这样的复杂模式。
但ES也不是银弹。有次我忘记配置合理