SQL能否实现动态JOIN，根据列内容切换匹配规则优化底盘号查询性能

1. 可直接运行的动态关联语法 #

你写的伪代码不符合SQL条件表达式的规范，把判断逻辑拆成两个互斥的分支用OR拼接即可实现需求，完整的JOIN条件写法如下：

select ...
from @TempTable temp
left join tblChassis ch 
on 
  (len(temp.ChassisNumber) = 17 AND ch.ChassisNumber = temp.ChassisNumber)
  OR 
  (len(temp.ChassisNumber) != 17 AND ch.ChassisNumber like '%' + temp.ChassisNumber + '%')

2. 性能优化建议 #

• 提前给临时表预计算长度标识，避免关联时重复计算字符串长度：
  可以在临时表中新增字段存储是否为完整17位底盘号的标识，插入数据时就完成计算，不需要每次关联时实时计算len()，还可以给该字段和ChassisNumber字段加联合索引进一步提升性能：

  declare @TempTable table(
    ChassisNumber varchar(17),
    IsFullLength bit
  )
  
  insert into @TempTable 
  values 
    ('WF0EXXTTREMG4210', case when len('WF0EXXTTREMG4210')=17 then 1 else 0 end),
    ('WF0JXXWPCHMB28874', case when len('WF0JXXWPCHMB28874')=17 then 1 else 0 end),
    ('WF0JXXWPCHMB', 0),
    ('MB28874', 0)
  
  -- 关联条件可以简化为
  on 
    (temp.IsFullLength = 1 AND ch.ChassisNumber = temp.ChassisNumber)
    OR 
    (temp.IsFullLength = 0 AND ch.ChassisNumber like '%' + temp.ChassisNumber + '%')
  

• 如果上述写法出现索引失效、性能不达标的情况，更推荐用UNION ALL拆分查询，性能远高于普通UNION：
  17位完整底盘号的匹配结果和非17位的匹配结果天然无重叠，不需要去重，用UNION ALL可以让两个分支的查询都走最优执行计划，17位的分支走等值索引，非17位的分支走模糊匹配逻辑，整体性能通常比单条SQL用OR拼接的写法更好。
• 如果业务上模糊匹配的使用频率很高，可以给tblChassis.ChassisNumber字段建立全文索引，优化带前后通配符的包含查询性能。

内容的提问来源于stack exchange，提问作者GuidoG