模糊匹配join不应出现在on条件中，因其导致全表扫描、索引失效、空值静默丢数据及字符集隐式转换等问题；应改用映射表等值连接或预过滤方案。
模糊匹配 JOIN 本身就不该出现在 ON 条件里——除非你明确接受全表扫描和性能雪崩。 直接在 ON 子句中对 JOIN 字段用 LIKE '%xxx%'，MySQL 或 PostgreSQL 都无法利用 B-Tree 索引加速，执行计划里必现 type: ALL 和 Using join buffer (Block Nested Loop)。
为什么 LIKE '%abc%' 在 JOIN 中必然慢
数据库的 B+ 树索引只支持最左前缀匹配。当写成 ON t1.name LIKE CONCAT('%', t2.keyword, '%') 时：
- 优化器无法将该表达式下推为索引查找，只能对每行
t1.name执行一次字符串扫描 - 如果
t2.keyword是 NULL（常见于 LEFT JOIN 场景），CONCAT('%', NULL, '%')返回 NULL，整行匹配失败，且不报错、无声丢数据 - 字符集不一致（比如
utf8mb4_unicode_civsutf8mb4_general_ci）会触发隐式CONVERT()，索引直接失效
前缀匹配（LIKE 'abc%'）怎么加索引才生效
只有严格满足“固定前缀 + 通配符在尾部”这一模式，普通 B-Tree 索引才能起效：
- 确保字段已建索引：
CREATE INDEX idx_user_name_prefix ON users(name); - JOIN 写法必须是
ON u.name LIKE CONCAT(t2.prefix, '%')，不能是LIKE CONCAT('%', t2.suffix, '%') - 若
t2.prefix来自右表且可能为空，务必用COALESCE(t2.prefix, '')，否则空值导致条件恒假 - MySQL 5.7+ 支持函数索引，但
LIKE表达式本身不能作为索引表达式；需显式建生成列，如：ALTER TABLE users ADD COLUMN name_prefix VARCHAR(64) GENERATED ALWAYS AS (SUBSTRING(name, 1, 64)) STORED;，再对name_prefix加索引
全文索引（FULLTEXT）在 JOIN 中的限制与绕过方法
全文索引确实能加速 MATCH ... AGAINST，但它在 JOIN 场景中几乎不可用：
- MySQL 的
FULLTEXT索引只支持在WHERE子句中使用，ON子句中写MATCH(t1.content) AGAINST(t2.keyword)会报错 - InnoDB 的全文索引不支持在 JOIN 的右表字段上做匹配（即不能用右表关键词去查左表全文字段）
- 可行路径只有两步：先用子查询从右表提取关键词集合，再用
IN或EXISTS关联左表，例如：SELECT * FROM articles a WHERE EXISTS (SELECT 1 FROM logs l WHERE l.message LIKE CONCAT('%', a.title, '%') AND l.status = 'done') - PostgreSQL 用户可考虑
pg_trgm+ GIN 索引，但同样不能直接用于ON，得改写为USING或子查询预过滤
真正稳定的方案：用映射表替代模糊 JOIN
90% 的业务模糊匹配需求（商户名归一、品牌别名、地址简称）其实不该靠实时 LIKE，而应前置清洗：
- 建一张
alias_map表，字段为canonical_name和variant，人工或规则填充（如 “支付宝” → “alipay”, “zfb”） - JOIN 改为等值连接：
INNER JOIN alias_map am ON u.name = am.variant，再SELECT am.canonical_name - 这个方案完全规避了模糊计算开销，索引命中率 100%，且结果确定、可测试、易维护
- 若 variant 数量极大，可在
variant上建哈希索引（MySQL 8.0+）或 GIN 索引（PostgreSQL）
模糊 JOIN 最容易被忽略的点，不是语法怎么写，而是没意识到：JOIN 本意是结构化关联，而模糊匹配本质是非结构化搜索。硬把两者塞进一条 SQL，等于让快递员一边查地图一边送包裹——不如先查好路线，再出发。
