数据库 - MySQL转换SQL Server时,替换 FIND_IN_SET 函数引发的问题

发布时间 2023-09-27 15:11:35作者: Helios_Fz

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函数的迁移问题,但这种针对这种复杂逻辑,如果时间允许的话,还是迁移到后台服务中好一些。