MySQL转换SQL Server时，替换 FIND_IN_SET 函数引发的问题

 在之前的文章中，我列举出了一个当 MySQL 转换 SQL Server 时，FIND_IN_SET 函数在 SQL Server 中的解决方案：链接

 就是使用

charindex(cast(匹配列 as varchar(50)), 被匹配列（多个用，分开的值）) <![CDATA[ > ]]> 0

替换 MySQL 中的 FIND_IN_SET。

但是！！！这个方案在生产环境中，引发了非常大的问题：比如匹配列是"8"，但被匹配列是"58,59"，这个判断依然是成立的，也就是说引起了错误的外键关联，这是非常危险且不可接受的。

所以我选取了如下方案去修复：

select *
from table1 t1
         left join (select t2.*,
                           '声明一个新的列' = substring(被匹配列, b.number,
                                                        charindex(',', 被匹配列 + ',', b.number) -
                                                        b.number)
                    from table2 t2
                             inner join master.dbo.spt_values b
                                        on b.number between 1 and len(被匹配列)
                                            and
                                           substring(',' + 被匹配列, b.number, 1) =
                                           ','
                    where b.type = 'P') t3 on t1.匹配列 = t3.新的列

其中 master.dbo.spt_values 是SQL Server 的内置表，具体作用可以在网络上找到，这里就不详细描述了。

虽然这种方式可以从根本上解决FIND_IN_SET函数的迁移问题，但这种针对这种复杂逻辑，如果时间允许的话，还是迁移到后台服务中好一些。