LIKE '%xxx%'无法使用索引导致全表扫描，JOIN后性能骤降；ON中用LIKE易报错或笛卡尔积；应优先精确JOIN+后过滤，或改用FULLTEXT/pg_trgm、LATERAL等优化方案。
JOIN时WHERE里写多个LIKE条件为什么性能差？
因为数据库无法对LIKE '%xxx%'这种前后缀都不固定的模式使用索引，JOIN后还要逐行扫描匹配，数据量一过万就明显卡顿。更糟的是，如果在ON子句里写LIKE，某些数据库（如MySQL 5.7）会直接报错或退化为笛卡尔积。
实操建议：
- 优先把模糊匹配逻辑移到JOIN之后的
WHERE中，确保JOIN本身基于精确字段（如id、category_id） - 若必须在关联条件中模糊匹配，改用
ON a.name LIKE CONCAT('%', b.keyword, '%')，但仅限小表驱动大表，且b.keyword需有明确业务约束（如长度≤10） - 考虑前置生成带通配符的映射表，比如把产品名“iPhone 15 Pro”拆成{“iphone”, “15”, “pro”, “iphone 15”, “15 pro”}存入关联表，用等值JOIN替代LIKE
用FULLTEXT或pg_trgm加速多字段模糊JOIN
原生LIKE不走索引，但FULLTEXT（MySQL）或pg_trgm（PostgreSQL）能真正加速多条件文本匹配。关键不是“能不能用”，而是“怎么嵌套进JOIN”。
实操建议：
- MySQL：在被搜索表建
FULLTEXT(name, description)，JOIN时用MATCH(a.name, a.description) AGAINST(b.query IN NATURAL LANGUAGE MODE)，注意b.query必须是单个字符串，不能是列引用 - PostgreSQL：启用
CREATE EXTENSION pg_trgm，对字段建GIN索引，JOIN条件写成ON a.name % b.keyword（相似度默认阈值0.3），再用similarity(a.name, b.keyword) > 0.4二次过滤 - 避免在
ON里混用%和=——比如ON a.status = b.status AND a.name % b.keyword，否则优化器可能放弃索引
LEFT JOIN + 多个OR LIKE条件的陷阱
有人写LEFT JOIN t2 ON t1.id = t2.t1_id WHERE t2.name LIKE '%a%' OR t2.name LIKE '%b%' OR t2.desc LIKE '%c%'，结果发现t1所有行都消失了——这是因为OR让LEFT JOIN实际退化成了INNER JOIN语义。
实操建议：
- 把模糊条件全挪到
ON里：LEFT JOIN t2 ON t1.id = t2.t1_id AND (t2.name LIKE '%a%' OR t2.name LIKE '%b%' OR t2.desc LIKE '%c%') - 若条件太多导致执行计划变差，拆成多个
LEFT JOIN，例如分别JOIN name匹配、desc匹配的子查询，再用COALESCE()合并结果 - 警惕
NULL参与OR：当t2.name为NULL时，t2.name LIKE '%x%'返回NULL而非FALSE，整个OR表达式可能变为UNKNOWN，被WHERE过滤掉
用LATERAL或APPLY实现每行独立模糊匹配
当主表每行需要匹配不同关键词（比如t1.row_id对应t2.keywords字段里的逗号分隔值），传统JOIN无法处理，硬拆字符串又低效。这时候LATERAL（PostgreSQL/SQL Server）或CROSS APPLY（SQL Server）才是正解。
实操建议：
- PostgreSQL示例：
SELECT t1.*, m.matched_name FROM t1 CROSS JOIN LATERAL ( SELECT name AS matched_name FROM t2 WHERE t2.name ILIKE '%' || t1.search_hint || '%' LIMIT 1 ) m;
- SQL Server必须用
CROSS APPLY，不能用OUTER APPLY除非你确定要保留无匹配的主表行 - 注意
LATERAL子查询里不能引用外部查询的聚合结果（如MAX(t1.id)），只能引用当前行的标量字段
模糊匹配叠加JOIN，最麻烦的从来不是语法，而是评估“哪边该先过滤”——关键词表小就驱动大表，文本字段长就优先走全文索引，字段含大量NULL就得提前COALESCE兜底。这些细节没压准，写得再漂亮的SQL也会在凌晨三点报警。
