SQL中LIKE不能直接用于JOIN条件，因多数数据库不支持或性能极差；应将模糊逻辑移至WHERE或EXISTS中过滤，或用CTE/子查询预生成匹配对，避免ON中动态拼接导致索引失效。
SQL中LIKE不能直接用于JOIN条件，但可以替代实现
直接在ON子句里写LEFT JOIN t2 ON t1.name LIKE '%' || t2.pattern || '%'看似合理，实际多数数据库（如MySQL 5.7、PostgreSQL）会拒绝执行或严重拖慢性能——因为无法使用索引，且LIKE左侧必须是固定列，右侧不能是另一张表的字段参与拼接（除非用函数索引+特定写法）。真正可行的是把模糊逻辑“移出来”：先生成候选集，再过滤。
用子查询或CTE预生成匹配对，再JOIN
这是最通用、可控的方式。核心思路是：不依赖JOIN ... ON ... LIKE，而是用WHERE或EXISTS做二次筛选。
- 对小表（如配置表
patterns）做笛卡尔积或交叉连接，再用WHERE t1.name LIKE t2.pattern过滤（注意：t2.pattern需含通配符，如'%apple%'） - 若
t2.pattern不含通配符，需手动拼接，例如WHERE t1.name LIKE '%' || t2.keyword || '%' - PostgreSQL支持
JOIN LATERAL，可让右表依赖左表值动态计算匹配项，避免全量交叉
示例（MySQL）：
SELECT t1.id, t1.name, t2.category
FROM products t1
JOIN categories t2
WHERE t1.name LIKE CONCAT('%', t2.keyword, '%');
不同数据库对LIKE + JOIN的支持差异很大
SQL标准不规定LIKE能否用于ON，各引擎行为不一：
- SQL Server允许
ON t1.col LIKE t2.pattern，但仅当t2.pattern是常量或参数时能走索引；若为列值，基本退化为嵌套循环+全表扫描 - Oracle 12c+ 支持
FUNCTION-BASED INDEX加速UPPER(col) LIKE UPPER(:p)类查询，但依然不能索引含列拼接的LIKE - SQLite完全不支持
ON中使用LIKE关联列，会报错no such column
所以别赌兼容性，统一用WHERE + 显式拼接更稳妥。
性能陷阱：前导通配符%会让索引彻底失效
只要LIKE模式以%开头（如'%abc'或'%abc%'），B-Tree索引就无法跳查，只能全表扫描。这是最容易被忽略的硬伤。
- 如果业务允许，把模糊方向倒过来：比如查“以某前缀开头”，就用
col LIKE 'abc%'，可走索引 - 需要全文模糊又高频，应改用全文检索（MySQL
FULLTEXT、PostgreSQLtsvector、Elasticsearch） - 临时方案：加
GENERATED COLUMN存n-gram切分结果，配合等值JOIN，但维护成本高
没有银弹。模糊连接本质是N×M复杂度操作，数据量过万就得考虑是否真该在SQL层做这件事。
