SQL Server用STRING_SPLIT需显式转换、去空格、去重；MySQL用FIND_IN_SET但无法索引且有长度限制；PostgreSQL用string_to_array+unnest需TRIM和类型转换；所有数据库均须校验参数NULL、空值、非法字符及长度。
SQL Server里用STRING_SPLIT函数拆分字符串
SQL Server 2016+ 支持 STRING_SPLIT，这是最直接的解法。它把逗号分隔的字符串转成单列结果集，能直接用于 IN 子查询或 JOIN。
常见错误是直接写 WHERE column IN (SELECT value FROM STRING_SPLIT(@param, ',')) 却忽略 value 列是 nvarchar(4000) 类型——如果目标字段是 int 或 uniqueidentifier，会隐式转换失败或索引失效。
- 显式转换：用
CAST(value AS int)或TRY_CAST(value AS int)（推荐后者，避免非法值报错） - 去空格：
TRIM(value)必须加，否则'1, 2,3'里的空格会导致匹配失败 - 去重：
STRING_SPLIT不去重，如需唯一值，外层套DISTINCT
MySQL中用FIND_IN_SET替代IN子句
MySQL 没有原生表值函数，FIND_IN_SET 是最常用且安全的方案。它接受一个值和一个逗号分隔字符串，返回位置（非零即匹配），绕过了动态拼SQL的风险。
注意 FIND_IN_SET 无法使用索引，大数据量时性能明显下降；而且它只支持字符串匹配，不能自动类型转换——比如字段是 int，传入 '1,2,3' 能工作，但传 '01,02' 就不匹配。
- 别用
CONCAT('%,', col, ',%')模糊匹配，容易误匹配（如'1'匹配到'11'） - 如果必须用
IN，只能靠应用层拼接，或升级到 MySQL 8.0+ 用JSON_TABLE解析 JSON 数组 -
FIND_IN_SET第二个参数长度上限是 1024 字符，超长会截断
PostgreSQL用string_to_array + unnest组合
PostgreSQL 推荐用 string_to_array(@param, ',') 得到文本数组，再用 unnest() 展开为行。比正则或递归 CTE 更简洁、性能更好。
关键坑在于：默认分割后元素带空格，unnest(string_to_array('1, 2, 3', ',')) 会产生 '1'、' 2'、' 3' —— 直接跟 int 字段比较会失败。
- 必须链式处理：
TRIM(unnest(string_to_array(@param, ','))) - 类型转换建议用
NULLIF(TRIM(...), '')::int，避免空字符串转整型报错 - 如果参数可能为空或全空白，
string_to_array('', ',')返回{''}，需加WHERE ... IS NOT NULL过滤
所有数据库都该避开的硬编码陷阱
不管用哪种方法，最常被忽略的是参数校验和边界情况。存储过程不是黑盒，传入 NULL、空字符串、含非法字符（如单引号、反斜杠）、超长字符串时，行为差异极大。
比如 SQL Server 中 STRING_SPLIT(NULL, ',') 返回空结果集，看似安全，但若后续逻辑依赖“至少一行”，就可能跳过校验分支；而 MySQL 的 FIND_IN_SET(NULL, '1,2') 返回 NULL，在 WHERE 条件里等于不成立，查不到数据却不报错。
- 强制前置检查：
IF @param IS NULL OR TRIM(@param) = '' RAISERROR(...) - 限制最大长度：防止恶意超长参数拖慢解析或爆内存
- 预清洗：用
REPLACE(REPLACE(@param, CHAR(13), ''), CHAR(10), '')去掉回车换行，避免隐形分隔符
真正麻烦的从来不是怎么拆，而是拆完之后每个值是否可信、类型是否对得上、空值怎么流过去——这些细节不压平，上线后就是半夜告警。
