徐小疼1. 问题背景：为什么LIKE '%abc%'查询这么慢？
在数据库查询优化领域，LIKE '%abc%'这类模糊查询一直是性能杀手。当我们在字符串字段上使用前导通配符查询时，常规的B树索引完全失效，数据库不得不进行全表扫描。对于百万级以上的数据表，这种查询可能耗时数秒甚至更久。
我最近处理的一个电商系统案例中，商品表的description字段有200万条记录，执行SELECT * FROM products WHERE description LIKE '%防水%'需要4.7秒。这种性能问题在需要实时响应的业务场景中是完全不可接受的。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 传统解决方案的局限性
2.1 常规索引为何失效
B树索引的工作原理是从左到右匹配字符串。当我们使用LIKE 'abc%'时，索引可以高效定位到以"abc"开头的记录。但LIKE '%abc'或LIKE '%abc%'这种查询模式破坏了索引的最左前缀匹配原则。
2.2 现有优化方案的不足
常见的解决方案包括：
- 全文索引：需要额外存储空间，且对中文支持有限
- 搜索引擎集成：架构复杂，增加系统维护成本
- 函数索引：部分数据库不支持，且有性能开销
3. 反向存储大法原理详解
3.1 核心思路
这个方法的精髓在于：将原始字符串反转存储，同时建立反转后的索引。这样LIKE '%abc'查询就变成了LIKE 'cba%'，可以利用常规B树索引。
3.2 具体实现步骤
- 添加反转字段：
sql复制ALTER TABLE products ADD COLUMN description_reverse VARCHAR(255);
UPDATE products SET description_reverse = REVERSE(description);
- 创建反转索引：
sql复制CREATE INDEX idx_description_reverse ON products(description_reverse);
- 改写查询语句：
sql复制SELECT * FROM products
WHERE description_reverse LIKE REVERSE('%防水') || '%';
4. 性能对比实测
在200万条记录的测试环境中：
| 查询方式 | 平均耗时 | 索引使用情况 |
|---|---|---|
| 原始LIKE查询 | 4700ms | 全表扫描 |
| 反向存储法 | 42ms | 索引范围扫描 |
性能提升超过100倍！更重要的是，随着数据量增长，这种性能优势会更加明显。
5. 实现细节与注意事项
5.1 字段维护策略
需要确保原始字段和反转字段的一致性：
sql复制-- 使用触发器自动维护
CREATE TRIGGER trg_product_desc
BEFORE INSERT OR UPDATE ON products
FOR EACH ROW
SET NEW.description_reverse = REVERSE(NEW.description);
5.2 查询优化技巧
- 对于
LIKE '%abc%'双通配查询，可以拆分为：
sql复制WHERE description LIKE 'abc%'
OR description LIKE '%abc'
OR description LIKE '%abc%'
并分别对后两种使用反向查询
- 考虑使用持久化计算列（MySQL 5.7+/SQL Server等支持）
6. 适用场景与限制
6.1 最佳使用场景
- 主要使用后缀匹配查询的系统（如手机号尾号查询）
- 数据量大且查询频繁的表
- 需要保持简单架构的场景
6.2 潜在限制
- 增加约10-15%的存储开销
- 需要修改现有查询语句
- 对超长文本字段效果有限
7. 生产环境部署建议
- 灰度发布：先在从库或测试环境验证
- 监控指标：
- 查询响应时间P99
- 索引命中率
- 存储空间增长
- 回滚方案：保留原始查询方式作为fallback
我在实际项目中采用这种方案后，系统高峰期相关查询的CPU使用率从75%降至15%，效果非常显著。对于需要处理大量模糊查询的应用，这确实是一个简单有效的优化手段。