数据库like查询太慢？优化like查询的实用技巧有哪些？

数据库中的LIKE查询是模糊查询的常用方式,但在数据量较大时，若使用不当会导致性能问题，优化LIKE查询需要从索引设计、查询改写、数据结构优化等多方面入手，结合具体业务场景选择合适的策略，以下从常见问题到具体优化方法展开分析，并提供实际案例参考。

LIKE查询的性能瓶颈

LIKE查询的性能问题主要源于全表扫描,当LIKE以通配符“%”开头时（如LIKE '%keyword'），数据库无法利用B-Tree索引的有序性，必须逐行扫描所有数据，导致查询效率低下，在包含百万级记录的用户表中，若执行SELECT * FROM users WHERE name LIKE '%张%'，数据库可能需要扫描全表，耗时长达数秒甚至更久，频繁的LIKE操作还会增加CPU和I/O负载，进一步影响整体性能。

优化LIKE查询的核心方法

避免前导通配符，优先使用后置通配符

B-Tree索引对前导通配符（在开头）失效，但对后置通配符（在结尾）有效。

• 低效查询：LIKE '%abc'（无法使用索引）
• 高效查询：LIKE 'abc%'（可利用索引）

若业务场景必须使用前导通配符,可考虑将数据反转后建立索引，对用户名建立反转索引：

-- 添加反转字段
ALTER TABLE users ADD COLUMN reverse_name VARCHAR(255);
-- 触发器或应用层填充反转值
UPDATE users SET reverse_name = REVERSE(name);
-- 建立索引
CREATE INDEX idx_reverse_name ON users(reverse_name);
-- 查询时使用反转后的通配符
SELECT * FROM users WHERE reverse_name LIKE REVERSE('%abc');

使用全文索引替代部分LIKE场景

对于文本搜索场景（如文章内容、评论），MySQL的全文索引（FULLTEXT）或搜索引擎（如Elasticsearch）是更优选择，全文索引支持分词和相关性排序，效率远高于LIKE。

-- 创建全文索引
ALTER TABLE articles ADD FULLTEXT INDEX ft_content(content);
-- 使用MATCH AGAINST替代LIKE
SELECT * FROM articles WHERE MATCH(content) AGAINST('数据库优化' IN NATURAL LANGUAGE MODE);

限制查询范围，减少数据扫描量

通过添加其他条件缩小查询范围,使LIKE操作仅在有限数据中执行。

-- 先通过索引字段筛选，再执行LIKE
SELECT * FROM users 
WHERE created_time >= '2023-01-01' 
AND name LIKE '张%';

使用覆盖索引（Covering Index）

若查询只需要索引列,可通过覆盖索引避免回表操作。

-- 建立包含查询列的复合索引
CREATE INDEX idx_name_id ON users(name, id);
-- 查询仅使用索引列
SELECT id, name FROM users WHERE name LIKE '李%';

分库分表或缓存策略

对于超大规模数据,可通过分库分表（如按姓名首字母分表）减少单表数据量，对高频查询结果使用缓存（如Redis），避免重复执行LIKE查询。

正则表达式与函数优化

部分LIKE场景可替换为正则表达式（REGEXP），但需注意性能差异，MySQL中REGEXP对前导通配符的优化有限，仍需测试验证，避免在WHERE子句中对列使用函数（如LIKE LOWER(name)），这会导致索引失效。

不同数据库的优化差异

数据库	优化方案
MySQL	全文索引、反转索引、前缀索引（如name(10)）
PostgreSQL	trigram索引（pg_trgm扩展）、全文搜索
Oracle	文本索引（CONTEXT索引）、函数索引
SQL Server	全文目录（Full-Text Catalog）、包含性全文索引

PostgreSQL使用pg_trgm扩展可支持前导通配符：

-- 安装扩展
CREATE EXTENSION pg_trgm;
-- 创建trigram索引
CREATE INDEX idx_name_trgm ON users USING gin(name gin_trgm_ops);
-- 支持前导通配符的查询
SELECT * FROM users WHERE name LIKE '%abc';

实际案例与效果对比

某电商平台商品表包含500万条记录,优化前后查询对比如下：
| 优化前方案 | 优化后方案 | 耗时（秒） |
|—————————|—————————|————|
| LIKE '%手机%'（全表扫描） | 全文索引 + 缓存 | 15.2 → 0.3 |
| LIKE '手机%'（无索引） | 添加后置通配符索引 | 8.7 → 0.1 |

通过结合全文索引和缓存,查询性能提升50倍以上。

相关问答FAQs

A: B-Tree索引的叶子节点按列值有序存储，前导通配符意味着匹配模式的开头是任意字符，数据库无法确定索引的起始位置，只能逐行扫描，在索引树上查找%abc时，无法直接定位到第一个以“abc”开头的节点，因此索引失效。

Q2: 对于必须使用前导通配符的场景，有哪些替代方案？
A: 可采用以下方法：

1. 反转索引：将列值反转后建立索引，查询时反转模式（如REVERSE('%abc')）。
2. 搜索引擎：使用Elasticsearch、Solr等专门处理全文搜索的引擎。
3. 前缀索引+分表：对高频前缀（如姓名首字母）分表，减少单表数据量。
4. 缓存热门结果：对高频查询的模糊结果缓存，避免实时扫描。