1. 问题背景：为什么LIKE '%abc%'查询这么慢？
在日常数据库查询中，我们经常会遇到需要模糊匹配字符串的场景。比如在电商平台搜索商品名称、在社交平台查找用户昵称，或者在企业系统中筛选客户信息。这时候很多人会自然而然地使用LIKE '%abc%'这样的查询条件。
但实际使用中，这种查询往往会带来严重的性能问题。我曾经处理过一个用户表查询案例，表中有约500万条记录，执行SELECT * FROM users WHERE nickname LIKE '%小明%'竟然需要8秒多才能返回结果。这显然无法满足线上业务的需求。
1.1 LIKE查询的性能瓶颈分析
LIKE查询慢的根本原因在于其无法有效利用索引。数据库索引的工作原理类似于书籍的目录 - 它们依赖于数据的已知前缀来快速定位记录。当我们使用LIKE 'abc%'时，数据库可以利用索引快速找到以"abc"开头的记录。但是当使用LIKE '%abc'或LIKE '%abc%'时，由于通配符出现在开头，数据库不得不进行全表扫描，逐行检查每条记录是否匹配模式。
举个例子，假设我们有一个包含用户邮箱的表，并建立了email字段的索引：
sql复制-- 能使用索引
SELECT * FROM users WHERE email LIKE 'john%@example.com';
-- 不能使用索引，必须全表扫描
SELECT * FROM users WHERE email LIKE '%@example.com';
1.2 真实业务场景中的影响
在我参与的一个电商项目中，商品搜索功能最初使用了LIKE '%关键词%'的实现方式。当商品表增长到100万条记录时，搜索响应时间经常超过3秒，导致用户体验极差。更严重的是，这类查询会占用大量数据库资源，在高并发场景下可能导致整个系统响应变慢。
2. 解决方案：反向存储+索引优化
经过多次实践和测试，我发现"反向存储+正向索引"的组合能有效解决这个问题。这个方案的核心思想是通过存储数据的反向形式，将后缀查询转换为前缀查询。
2.1 反向存储的实现方法
以存储邮箱为例，我们可以在表中新增一个反向存储的字段：
sql复制ALTER TABLE users ADD COLUMN email_reverse VARCHAR(255);
UPDATE users SET email_reverse = REVERSE(email);
然后为这个反向字段创建索引：
sql复制CREATE INDEX idx_email_reverse ON users(email_reverse);
2.2 查询时的转换技巧
当需要查询以特定字符串结尾的记录时，我们可以这样操作：
sql复制-- 原始查询（无法使用索引）
SELECT * FROM users WHERE email LIKE '%@example.com';
-- 优化后的查询（可以使用索引）
SELECT * FROM users WHERE email_reverse LIKE REVERSE('@example.com') || '%';
2.3 性能对比测试
在我的测试环境中，对一个包含500万条记录的表进行查询：
| 查询类型 | 执行时间 | 是否使用索引 |
|---|---|---|
| LIKE '%@example.com' | 4800ms | 否 |
| 反向存储查询 | 42ms | 是 |
性能提升了超过100倍！这个优化效果在数据量越大时越明显。
3. 完整实施方案与注意事项
3.1 实施步骤详解
-
添加反向字段：
sql复制ALTER TABLE your_table ADD COLUMN column_name_reverse VARCHAR(255); -
初始化反向数据：
sql复制UPDATE your_table SET column_name_reverse = REVERSE(column_name); -
创建反向索引：
sql复制CREATE INDEX idx_column_reverse ON your_table(column_name_reverse); -
修改应用代码：
将所有LIKE '%后缀'查询替换为对反向字段的查询。 -
考虑触发器维护（可选）：
如果原字段会频繁更新，可以创建触发器自动维护反向字段：sql复制CREATE TRIGGER trg_reverse_column BEFORE UPDATE ON your_table FOR EACH ROW SET NEW.column_name_reverse = REVERSE(NEW.column_name);
3.2 实际应用中的注意事项
-
存储空间考虑：
反向存储方案需要额外的存储空间。对于大型表，需要评估存储成本。我曾经遇到一个案例，添加反向字段使表大小增加了15%，但查询性能的提升完全值得这个代价。 -
写入性能影响：
每次插入或更新记录时，都需要维护反向字段。在高写入负载的系统中，这可能会带来一定的性能开销。解决方案是可以考虑异步更新反向字段。 -
字符集和排序规则：
确保反向字段使用与原字段相同的字符集和排序规则，否则可能会出现匹配不一致的问题。 -
组合查询优化：
对于需要同时匹配前缀和后缀的查询（如LIKE 'abc%def'），可以结合正向和反向索引：sql复制SELECT * FROM table WHERE column LIKE 'abc%' AND column_reverse LIKE REVERSE('def') || '%';
4. 替代方案比较
虽然反向存储方案效果显著，但它并非唯一解决方案。下面比较几种常见的优化方法：
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 反向存储 | 性能提升显著，实现简单 | 需要额外存储空间 | 后缀匹配查询 |
| 全文索引 | 支持复杂搜索，功能强大 | 配置复杂，占用资源多 | 文本内容搜索 |
| 搜索引擎 | 搜索性能极佳 | 系统复杂度高，数据同步延迟 | 大型搜索系统 |
| 冗余字段 | 灵活度高 | 维护成本高 | 特定业务场景 |
在我的经验中，对于简单的后缀匹配需求，反向存储通常是性价比最高的方案。而对于复杂的文本搜索需求，可能需要考虑全文索引或专用搜索引擎。
5. 实战案例分享
5.1 电商平台商品搜索优化
某电商平台商品表有300万条记录，商品编号格式为"品类-日期-序列号"(如"ELEC-20230515-001")。业务需要按序列号后缀查询商品（如查询所有以"123"结尾的商品编号）。
优化前：
sql复制-- 执行时间：3.2秒
SELECT * FROM products WHERE product_code LIKE '%123';
优化步骤：
- 添加反向字段并建立索引
- 修改查询为：
sql复制-- 执行时间：28毫秒 SELECT * FROM products WHERE product_code_reverse LIKE REVERSE('123') || '%';
5.2 用户行为日志分析
在一个用户行为分析系统中，需要查询特定URL路径结尾的访问记录。原始URL存储形式为完整的URL，查询如：
sql复制SELECT * FROM access_log WHERE url LIKE '%/checkout';
通过反向存储优化后，查询性能从平均1.8秒提升到15毫秒，同时数据库CPU使用率下降了40%。
6. 高级技巧与扩展应用
6.1 多字段组合优化
对于需要同时查询多个字段的情况，可以创建复合反向索引。例如，同时按姓名和城市后缀查询：
sql复制ALTER TABLE customers
ADD COLUMN name_reverse VARCHAR(100),
ADD COLUMN city_reverse VARCHAR(100);
CREATE INDEX idx_name_city_reverse ON customers(name_reverse, city_reverse);
-- 优化后的查询
SELECT * FROM customers
WHERE name_reverse LIKE REVERSE('son') || '%'
AND city_reverse LIKE REVERSE('York') || '%';
6.2 部分反向索引
对于很长的字符串，有时只需要对最后一部分建立反向索引。例如，对于长URL，可能只需要对最后两段路径建立反向索引：
sql复制UPDATE urls SET path_end_reverse = REVERSE(SUBSTRING_INDEX(path, '/', -2));
6.3 函数索引的替代方案
在一些支持函数索引的数据库（如PostgreSQL）中，可以直接创建反向函数索引而无需额外字段：
sql复制CREATE INDEX idx_email_reverse ON users(REVERSE(email));
但在MySQL等不支持函数索引的数据库中，仍需使用反向字段方案。
7. 常见问题解答
Q：反向存储方案适用于所有数据库吗？
A：基本适用于所有关系型数据库，包括MySQL、PostgreSQL、Oracle等。具体语法可能需要微调。
Q：如何处理NULL值？
A：在创建反向字段时，建议设置默认值或使用COALESCE函数：
sql复制UPDATE table SET reverse_column = REVERSE(COALESCE(original_column, ''));
Q：反向索引会影响原有索引吗？
A：不会。反向索引是独立的新索引，不会影响原有索引的使用。
Q：中文字符反向存储是否会有问题？
A：不会。REVERSE函数对多字节字符（如中文）也能正确处理。但在某些特殊情况下可能需要考虑字符集一致性。
Q：有没有更简单的替代方案？
A：如果查询模式固定（如总是查询最后N个字符），可以考虑直接存储后缀：
sql复制ALTER TABLE users ADD COLUMN email_suffix VARCHAR(50);
UPDATE users SET email_suffix = RIGHT(email, 10); -- 存储最后10个字符
CREATE INDEX idx_email_suffix ON users(email_suffix);
8. 维护与监控建议
实施反向存储方案后，建议建立以下监控机制：
-
定期检查数据一致性：
sql复制-- 检查反向字段是否正确 SELECT COUNT(*) FROM table WHERE REVERSE(column_name) != column_name_reverse; -
监控查询性能：
记录优化前后关键查询的执行时间，确保优化效果持续。 -
存储空间监控：
关注表大小的增长情况，特别是对于大型表。 -
写入性能监控：
如果使用触发器维护反向字段，需要监控INSERT/UPDATE操作的性能影响。
在实际项目中，我曾经遇到过由于未及时维护反向字段导致查询结果不一致的问题。后来我们建立了每日数据校验任务，确保反向字段始终与原字段保持同步。