LIKE模糊匹配在JOIN中性能骤降，主因是%keyword%导致全表扫描；应移出JOIN条件，改用等值过滤后WHERE处理，或用前缀匹配、函数索引、全文索引及EXISTS替代。
LIKE模糊匹配时JOIN性能突然变慢，怎么办
直接在 ON 或 WHERE 中对大字段（如 name、description）用 LIKE '%keyword%' 做多表连接，几乎必然导致全表扫描和索引失效。MySQL 和 PostgreSQL 都不支持对通配符前置的 LIKE 使用普通 B-tree 索引；SQL Server 虽有全文索引，但默认也不走。
实操建议：
- 优先把模糊逻辑从
JOIN条件里移出去：先用等值或范围条件缩小主表数据集，再对结果集做LIKE过滤 - 若必须在
ON中模糊关联（例如匹配别名、拼音缩写），改用前缀匹配LIKE 'abc%'—— 这种能命中 B-tree 索引最左前缀 - PostgreSQL 可建
pg_trgm扩展 +GIN索引加速%keyword%查询，但仅适用于WHERE，不能用于JOIN ON的哈希/合并连接优化 - MySQL 8.0+ 支持函数索引，可对
LEFT(name, 10)建索引辅助前缀匹配，但无法解决中间通配
LEFT JOIN + LIKE 后出现重复或丢失记录，怎么定位
模糊匹配天然一对多，LEFT JOIN 遇到 ON t1.name LIKE CONCAT('%', t2.keyword, '%') 这类条件时，只要一个 t1.name 匹配多个 t2.keyword，就会产生笛卡尔膨胀；反过来，若 t2 没有匹配项，t1 行仍保留，但字段为 NULL —— 容易误判为“没连上”。
实操建议：
- 加
COUNT(*)或GROUP_CONCAT(t2.id)辅助观察匹配数量，确认是否真的一对多 - 用
EXISTS (SELECT 1 FROM t2 WHERE t1.name LIKE CONCAT('%', t2.keyword, '%'))替代LEFT JOIN，避免重复行，语义更清晰 - 若需取匹配中的某一条（如最早/最高分），在子查询中用
ROW_NUMBER() OVER (PARTITION BY t1.id ORDER BY t2.score DESC)标记后过滤
不同数据库对 LIKE JOIN 的语法兼容性差异
标准 SQL 不禁止 LIKE 出现在 ON 子句，但各引擎优化策略和限制不同。比如 SQLite 允许任意表达式，但无统计信息，容易选错执行计划；Oracle 对 ON 中的函数表达式更保守，可能拒绝使用索引。
实操建议：
- MySQL：确保被匹配字段（如
t1.title）和匹配值（如t2.pattern）字符集一致，否则隐式转换导致索引失效，错误提示可能是Using where; Using join buffer - PostgreSQL：避免在
ON中用ILIKE（大小写不敏感），它无法利用pg_trgm索引，应统一转小写后用LIKE - SQL Server：若用
CHARINDEX(t2.keyword, t1.text) > 0替代LIKE，有时执行计划更稳定，且可配合计算列索引
用全文检索替代 LIKE JOIN 的实际门槛
真正想靠模糊语义连接多表，LIKE 是临时方案，全文检索（FTS）才是正解，但落地有硬约束：不是所有字段都适合建全文索引，且跨表关联需额外映射逻辑。
实操建议：
- MySQL：仅
MyISAM和InnoDB支持FULLTEXT，且要求所有参与列在同一张表；跨表需先CREATE VIEW合并字段，再对其建索引（5.7+ 支持视图全文索引） - PostgreSQL：用
to_tsvector()+@@操作符，但JOIN时需在ON中写to_tsvector('chinese', t1.content) @@ to_tsquery('chinese', t2.query)，注意语言配置和停用词影响召回率 - 不要忽略更新延迟：全文索引不实时，尤其高并发写入场景下，刚插入的数据可能查不到
模糊匹配进 JOIN 是权衡之举，越想“像人一样理解文本”，就越要接受它带来的性能折损和逻辑复杂度。真正棘手的不是语法怎么写，而是想清楚——这个“模糊”到底是业务真实需求，还是因为上游数据没清洗干净。
