MySQL中的通配符主要用于LIKE或RLIKE等模式匹配操作，常见的是
%和
_。这些通配符本身不能直接用于JOIN条件中作为连接字段的常规比较方式，但可以在特定场景下结合字符串匹配函数实现模糊关联。
通配符在JOIN中的使用限制
标准的JOIN操作基于等值匹配（如
t1.id = t2.id），而通配符属于模式匹配范畴，无法直接参与索引优化的精确连接。因此，以下写法是无效的： 错误示例：
SELECT * FROM table1 t1 JOIN table2 t2 ON t1.name = 'user_%' -- 这不是通配符正确用法
这里的
'user_%'只是一个普通字符串，不会触发模式匹配逻辑。
通过LIKE实现模糊JOIN
虽然不能直接使用通配符进行等值连接，但可以利用
LIKE操作符在ON子句中完成基于模式的关联，这是通配符在JOIN中最常见的应用方式。
适用场景举例：根据用户昵称前缀匹配标签规则
SELECT t1.username, t2.rule_name FROM users t1 JOIN nick_rules t2 ON t1.username LIKE t2.pattern;
假设
nick_rules.pattern存储了类似
'admin%'、
'test_%'这样的规则，该查询能找出所有符合命名规则的用户。 支持
%：匹配任意长度字符（包括零字符） 支持
_：匹配单个字符 性能提示：这类JOIN通常无法使用索引加速，数据量大时应谨慎使用
结合函数处理复杂匹配需求
某些情况下，可配合字符串函数提取关键信息后再做模式判断。例如从邮箱域名角度分类用户来源：
SELECT u.email, p.partner_name FROM user_info u JOIN partners p ON SUBSTRING_INDEX(u.email, '@', -1) LIKE p.domain_pattern;
此例中通过
SUBSTRING_INDEX提取邮箱域名，并与合作伙伴配置的域名通配规则对比。
注意：这种操作会显著影响执行效率，建议在小表或预处理结果集上使用。
替代方案建议
若频繁需要模糊匹配关联，考虑以下优化路径：
提前将可枚举的分类信息固化为外键字段，避免运行时计算 使用全文索引+MATCH...AGAINST处理文本相关性匹配 借助应用程序逻辑分步查询，减少数据库层复杂度基本上就这些。通配符虽不能直接用于标准JOIN语法，但通过LIKE等操作可在ON条件中实现灵活的模糊关联，关键是理解其性能代价并合理设计数据结构。
