不能把逗号串当IN参数用，必须拆成行集或显式转型；SQL Server 2016+推荐STRING_SPLIT但需处理类型、空值和空格；老版本需自定义函数并注意返回列名与清洗；MySQL慎用FIND_IN_SET，不支持索引且要求字段为原子值；所有数据库均须校验类型、空值和脏字符。
直接结论：不能把逗号串当 IN 的参数用，必须拆成行集或显式转型，否则 IN (@param) 永远只匹配单个字符串值。
SQL Server 2016+：用 STRING_SPLIT 最省事
这是目前最推荐的解法，但有几个硬性前提要满足：
-
STRING_SPLIT返回的value是NVARCHAR(4000)，如果字段是INT（比如id），必须手动CAST(value AS INT)，否则隐式转换失败或走全表扫描 - 传入空串
''或NULL时，STRING_SPLIT返回空结果集，WHERE id IN (SELECT ...)变成空条件 → 查不到任何数据，得加判空：AND @ids IS NOT NULL AND @ids != '' - 如果传入字符串含多余空格（如
'1, 2 , 3'），CAST会报错，需提前清洗：REPLACE(REPLACE(@ids, ' ', ''), CHAR(9), '')
示例片段：
WHERE id IN ( SELECT CAST(value AS INT) FROM STRING_SPLIT(LTRIM(RTRIM(@ids)), ',') WHERE value != '' )
SQL Server 2014 及更老版本：必须建自定义拆分函数
老版本没 STRING_SPLIT，常见翻车点不是语法错，而是函数返回类型和调用方式不匹配：
- 别用动态 SQL（
EXEC(...)）拼IN ('1','2','3')—— 执行计划无法复用，且@ids含单引号或恶意字符时直接被注入 - 函数返回的列名必须明确（比如叫
col或id_val），否则IN (SELECT col FROM f_split(@ids, ','))会报“列名无效” - 函数体内没处理首尾空格，传入
' 1 , 2 '会导致CONVERT(INT, ' 1 ')失败，建议在函数里就用LTRIM(RTRIM(...))
典型函数调用写法：
WHERE id IN ( SELECT CONVERT(INT, LTRIM(RTRIM(col))) FROM dbo.f_split(@ids, ',') WHERE col != '' )
MySQL：别迷信 FIND_IN_SET，它不是万能胶
FIND_IN_SET 看起来简单，但只适合「字段值是否落在逗号串中」这种单次判断，不能替代真正的数组拆分：
- 顺序绝对不能反：
FIND_IN_SET(tag_name, @tags)✅；FIND_IN_SET(@tags, tag_name)❌（永远返回 0） - 字段值本身要是原子值（如
'tech'），而@tags是逗号串（如'music,tech,dev'）；如果字段存的是逗号串（如'music,tech'），那FIND_IN_SET就失效了 - 不支持索引，大数据量时性能断崖下跌；字段含空格、中文逗号、换行符都会导致匹配失败，必须清洗：
REPLACE(REPLACE(@tags, ' ', ','), ' ', '')
真正需要遍历每个 ID 做逻辑处理（比如逐个调用另一个存储过程），就得用 SUBSTRING_INDEX + WHILE 循环或 JSON 函数（MySQL 5.7+）。
所有数据库都绕不开的三个坑
无论用哪种拆分方式，以下三点不手动处理，90% 的问题都出在这儿：
-
类型不一致：参数是字符串，目标字段是数字 → 必须显式转型（
CAST/CONVERT/TO_NUMBER），不能依赖隐式转换 -
空值穿透：参数为
NULL或全空白时，整个子查询返回空，IN条件恒假 → 必须前置校验：AND @ids IS NOT NULL AND TRIM(@ids) != '' - 脏字符污染：英文逗号混中文逗号、前后空格、制表符、换行符 → 不清洗就拆分，轻则匹配失败，重则转型报错
这些不是“可选优化”，是每次写这类逻辑前必须检查的底线动作。
