1. 模糊查询的本质与挑战
第一次接触模糊查询需求时，我天真地以为这就是个简单的LIKE操作。直到线上系统因为"%关键词%"查询导致全表扫描，数据库CPU直接飙到100%，才意识到模糊匹配的水有多深。本质上，模糊查询是在不确定完整数据形态的情况下，通过部分特征进行信息检索，这种不确定性注定了它与传统精确查询完全不同的技术路线。
常规的B树索引在模糊查询场景下几乎失效，特别是前导通配符查询（如"%关键字"）。我曾测试过在百万级数据的用户表中查询"%技术%"这样的模式，即使字段有索引，MySQL依然选择了全表扫描，响应时间从毫秒级暴跌到秒级。这背后的原理是B树索引的排序特性决定了它只能高效支持前缀匹配（如"技术%"），而无法应对中间或后缀模糊匹配。
更棘手的是中文场景下的分词问题。英文单词天然有空格分隔，但中文需要额外处理。"数据库技术"如果被存储为连续字符串，查询"数据%"还能利用索引，但查询"%技术%"就无能为力。某次处理用户搜索日志时发现，超过60%的模糊查询都包含中文中间匹配，这直接促使我们开始研究专业搜索引擎方案。
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也不是银弹。有次我忘记配置合理的分片数，在数据量增长到2亿条时查询性能急剧下降。后来通过hot-warm架构优化，将热数据放在SSD节点，冷数据迁移到HDD节点，才解决了这个问题。这提醒我们：分布式系统的性能不仅取决于算法，资源调度同样关键。
2.3 新兴的专用数据库
Redis的RediSearch模块给了我很大惊喜。在某个需要实时前缀补全的项目中，我们使用它的FT.CREATE命令创建索引，配合%关键词%查询，性能比MySQL快了近百倍。内存数据库的优势在此尽显，但代价是数据规模受RAM限制。
更惊艳的是ClickHouse的ngramDistance函数。在处理日志分析时，它能快速找出与目标字符串相似的所有记录。有次排查问题需要找出所有包含"error"但拼写近似的日志，ClickHouse在秒级就返回了结果，而传统方法需要编写复杂的正则表达式。
3. 实战中的架构设计策略
3.1 混合存储方案设计
现在我的标准做法是采用分层存储架构。在最近的一个社交平台项目中，核心用户表仍放在PostgreSQL保证ACID，同时通过Debezium将数据实时同步到Elasticsearch集群。这样精确查询走关系库，模糊搜索走ES，两边各司其职。关键在于同步延迟的控制——我们最终实现了200ms内的数据一致性。
缓存层的设计也很有讲究。对于高频模糊查询，我会用Redis缓存结果集，但特别注意设置合理的TTL。曾经因为缓存过期时间设得太长，导致用户看不到最新发布的商品，被运营团队追着骂了一周。现在我的原则是：静态数据缓存24小时，动态数据不超过5分钟。
3.2 查询优化技巧
分词策略直接影响查询效率。对比过IK、jieba等中文分词器后，我发现没有放之四海皆准的方案。在电商场景下，IK的细粒度模式更适合商品标题；而在社交内容搜索时，jieba的搜索引擎模式效果更好。建议在项目初期就进行AB测试，选择最符合业务特性的分词器。
对于必须使用MySQL LIKE的场景，我总结了几条救命法则：
- 绝对避免"%关键词%"这样的双通配符查询
- 必要时使用反向索引技巧：新增一列存储reverse(title)，对"关键词%"查询改为reverse_title LIKE reverse('关键词')+'%'
- 考虑使用FULLTEXT索引替代LIKE，但要注意其不支持中文的局限
4. 性能对比实测数据
为了给团队选型提供依据，我最近做了一次系统的基准测试。环境为16核32GB的云服务器，测试数据量为5000万条模拟商品记录：
| 数据库类型 | 查询示例 | 平均响应时间 | 索引大小 | QPS |
|---|---|---|---|---|
| MySQL(无索引) | LIKE '%手机%' |
4200ms | - | 2 |
| MySQL(B树索引) | LIKE '手机%' |
25ms | 1.2GB | 150 |
| PostgreSQL(pg_trgm) | LIKE '%手机%' |
80ms | 3.8GB | 90 |
| Elasticsearch(ngram) | "*手机*" |
45ms | 6.5GB | 220 |
| RediSearch | "%手机%" |
8ms | 4.2GB | 500 |
这个测试揭示了一个有趣的现象：专用搜索系统的写入性能往往只有关系型数据库的1/5，但查询性能却能高出10倍以上。这印证了数据库领域永恒的真理：没有完美的系统，只有合适的取舍。
5. 踩坑实录与救火经验
记忆最深刻的是一次618大促前的压测。我们自以为准备充分，ES集群配置了充足的资源。但真实流量来袭时，一个模糊查询DSL中的"minimum_should_match": "75%"参数导致CPU打满。原来这个参数会强制ES进行复杂的相关性计算，在QPS超过2000时就成了性能杀手。最后的应急方案是降级为简单的term查询，虽然召回率下降，但保住了系统可用性。
另一个教训是关于数据同步的。有次ES索引的mapping设置不当，导致商品价格被错误识别为text而非float。结果用户搜索"1999"时匹配不到标价1999元的商品，因为文本分词后变成了"1","9","9","9"。这种数据一致性问题往往在深夜爆发，我现在养成了上线前必查mapping的习惯。