like模糊查询慢的核心原因是索引未被有效利用或技术路径选择不当；仅前缀匹配（如'张%'）、等值+前缀、全匹配可走b-tree索引，而'%张%'等无法使用普通索引，需用全文索引、冗余字段、分区裁剪或切换es等方案优化。
SQL报表中用 LIKE 做模糊查询慢，核心问题往往不是语法写得不对，而是没用对索引或没选对技术路径。盲目加索引、改写 SQL 很可能无效，甚至更慢。
LIKE 能走索引的几种情况
只有满足特定模式的 LIKE 才能利用普通 B-Tree 索引：
-
前缀匹配：如
WHERE name LIKE '张%'—— 可走索引（最左前缀原则） -
等值 + 前缀：如
WHERE status = 1 AND title LIKE '报表%'—— 复合索引(status, title)有效 -
全匹配：如
WHERE code LIKE 'A123'—— 等价于=，当然走索引
以下情况无法使用普通索引：LIKE '%张%'、LIKE '%张'、LIKE CONCAT('%', @key, '%')。此时数据库只能全表扫描。
替代方案：全文索引（FULLTEXT）
适合字段内容较长、需支持“包含任意词”的模糊检索，比如报表标题、说明、日志文本：
- MySQL MyISAM 和 InnoDB（5.6+）均支持，建表时加
FULLTEXT(title, content) - 查询改用
MATCH(title) AGAINST('销售报表' IN NATURAL LANGUAGE MODE) - 注意：不支持通配符前缀，但支持分词匹配；中文需搭配
ngram插件（MySQL 5.7+）或使用第三方分词器预处理
全文索引不适合精确前缀或数字类模糊（如编号模糊查 '2024-001%'），这类仍应靠 B-Tree 索引优化。
其他实用提速手段
不依赖索引也能显著改善体验：
-
加 LIMIT：报表常只需前几百条，
LIKE ... LIMIT 50可避免扫完整表 -
冗余字段预计算：如常查“含‘月报’且状态为启用”，可新增布尔字段
is_monthly_report并用触发器或应用层维护 -
分区裁剪：按时间分区的报表表，先用
WHERE report_date >= '2024-01-01'缩小范围，再做 LIKE -
避免函数包裹列：写成
WHERE UPPER(title) LIKE UPPER('%销售%')会失效索引；应统一存储规范格式，或用生成列+索引
什么时候该放弃 LIKE，换技术栈？
当模糊查询成为高频、高并发、低延迟刚需（如报表搜索框实时响应），传统 SQL 已非最优解：
- 数据量大（千万级以上）、字段多、模糊逻辑复杂 → 考虑 Elasticsearch 或 Solr
- 内部系统、对部署轻量有要求 → 可用 SQLite FTS5 或 PostgreSQL 的 pg_trgm + GIN 索引
- 已有数仓（如 StarRocks、Doris）→ 利用其内置全文或 LIKE 向量化加速能力
单纯调优 LIKE 很难突破 I/O 和算法瓶颈，架构层面的取舍有时比 SQL 改写更重要。
