会，性能急剧下降；因LIKE '%xxx'无法走索引，JOIN时触发全表扫描式匹配，1万×1万达1亿次比对，索引失效。

JOIN里直接用LIKE做关联，性能会崩吗？

会，而且崩得很快。数据库无法对LIKE '%xxx'这种左通配模式走索引，JOIN时相当于对每行都做全表扫描式匹配，1万行 × 1万行就是1亿次字符串比对。哪怕加了索引，只要开头是%，索引就失效。

实操建议：

• 优先把模糊逻辑移到应用层：先用精确条件（如city_id）缩小结果集，再用Python/JS做str.contains()过滤
• 真要SQL里做，改用LIKE 'prefix%'（右通配），确保前缀固定且有索引支持
• MySQL 8.0+ 可考虑REGEXP_LIKE()配合函数索引，但仅限简单模式，别写.*abc.*

ON子句中写LIKE和WHERE里写，有区别吗？

有本质区别。放在ON里是关联逻辑的一部分，影响驱动表与被驱动表的匹配行为；放在WHERE里是关联完成后的过滤，可能让本该保留的左表记录被丢弃（尤其LEFT JOIN）。

常见错误现象：LEFT JOIN t2 ON t1.name LIKE CONCAT('%', t2.keyword, '%') 看似合理，但一旦t2.keyword为空或含特殊字符（如%、_），匹配结果完全不可控。

实操建议：

• 避免在ON里用动态LIKE，除非你明确知道驱动表顺序且t2.keyword内容可信
• 若必须模糊关联，先用GENERATE SERIES（PostgreSQL）或数字辅助表拆分关键词，转成等值JOIN
• MySQL用户可预计算MD5(name)或SOUNDEX(name)存为冗余字段，用等值JOIN加速

想模糊匹配又不想拖慢查询，有没有轻量替代方案？

有，但要看场景。核心思路是把“运行时模糊”变成“预计算确定性映射”。

使用场景举例：商户名称匹配、地址简称归一化、品牌别名合并。

实操建议：

• 建一张alias_map表，人工或规则生成canonical_name → variant映射，用=关联代替LIKE
• 对短文本（LEVENSHTEIN()（PostgreSQL）或EDITDISTANCE()（SQL Server），但务必加LIMIT和前置长度筛选
• SQLite用户直接上FUZZY扩展，但注意它不支持参数化，SQL注入风险高

MySQL 5.7用JOIN ... LIKE报ERROR 1054？

大概率是字段未加表别名限定，比如写成ON name LIKE CONCAT('%', keyword, '%')，而name和keyword在两个表里都存在，MySQL无法推断归属。

错误信息：Unknown column 'keyword' in 'on clause'

实操建议：

• 所有字段必须带表别名：ON t1.name LIKE CONCAT('%', t2.keyword, '%')
• 确认t2.keyword不是NULL——CONCAT('%', NULL, '%')结果是NULL，导致整行匹配失败
• 用COALESCE(t2.keyword, '')兜底，但注意空字符串会导致LIKE '%%'，全匹配

模糊匹配关联从来不是“加个LIKE就行”的事，真正卡住人的往往是索引失效的静默发生、NULL值引发的逻辑断裂，还有不同数据库对通配符转义的处理差异。