怎样在SQL存储过程中实现动态的IN查询：使用XML或JSON传递数组

SQL Server里用XML参数解析IN列表的实操要点

在SQL Server里，想把一个数组直接塞进存储过程当参数？这事儿它原生就不支持。你IN子句里那一串值，最终都得老老实实展开成逗号分隔的字面量。所以，用XML来传，尤其是在SQL Server 2005及以后的版本里，算是个比较稳妥的老办法。

但问题的关键，从来不是“能不能用”，而是“怎么用才能不翻车”。常见的坑有两个：一是用了sp_xml_preparedocument来准备文档，结果忘了用EXEC sp_xml_removedocument来清理，内存泄漏就这么悄无声息地发生了；二是路径写死了，比如/root/item，一旦前端传过来的XML结构稍有变动，查询结果直接就空了。

• 参数声明：直接声明为@xmlData XML类型，别用VARCHAR再转换，否则格式丢失或者编码问题会让你头疼。
• 解析规范：用OPENXML配合WITH子句时，务必显式定义字段类型，比如id INT '@id'。依赖隐式转换？失败的风险可不小。
• 性能红线：如果IN列表里的项数超过2000，就别再死磕XML了。OPENXML处理太多节点会明显变慢。这时候，改用临时表配合INSERT ... SELECT分批加载，才是正道。

DECLARE @hdoc INT;
EXEC sp_xml_preparedocument @hdoc OUTPUT, @xmlData;
SELECT id FROM OPENXML(@hdoc, '/root/item', 2) WITH (id INT '@id');

SQL Server 2016+用STRING_SPLIT处理JSON字符串的限制

看到STRING_SPLIT这个函数，很多人会想当然地以为它能直接处理JSON数组字符串，比如'["a","b","c"]'——这可就错了。STRING_SPLIT只认最纯粹的、用逗号分隔的字符串，对JSON里的方括号、引号、转义字符这些“装饰品”完全无感。你直接丢给它，它会把整个JSON字符串当成一个值来处理。

真想用JSON？那得请出SQL Server 2016引入的OPENJSON。不过它也有脾气：输入必须是合法的JSON文本，而且默认只解析第一层结构。常见的翻车现场是，JSON里混入了null值或者数字，但WITH子句里没定义对应的类型，导致解析出来的字段全是NULL。

• 参数类型：JSON字符串参数务必用NVARCHAR(MAX)，用VARCHAR可能导致中文乱码或者解析意外终止。
• 路径明确：OPENJSON(@json, '$')里的路径参数要写清楚。'$'表示根路径，如果是嵌套数组，可能需要写成'$.items'。
• 对象数组处理：如果JSON数组里每个元素都是对象（比如[{"id":1},{"id":2}]），那么在WITH子句里必须声明路径，如id INT '$.id'，光写个id INT是取不到值的。

SELECT value FROM OPENJSON(@json) WITH (value NVARCHAR(100) '$');

PostgreSQL用VARIADIC参数替代IN的更简方案

其实，PostgreSQL完全不用像SQL Server那样绕弯子。它原生就支持VARIADIC数组参数。这意味着，你可以让存储过程直接接收TEXT[]或INT[]这样的数组，然后在查询里用= ANY()操作符来代替IN子句，既安全又高效。

不过，这个方案有个细节特别容易被忽略：调用函数时，必须显式加上VARIADIC关键字，否则PostgreSQL会报错，提示“函数期望数组类型，却收到了文本”。另外，如果你传了一个空数组{}进去，= ANY()会永远返回false，所以记得在函数内部做好空数组的判断和处理。

• 定义函数：要写成my_func(VARIADIC ids INT[])，而不是简单的ids INT[]。
• 调用函数：要写成SELECT my_func(VARIADIC ARRAY[1,2,3]);，漏掉VARIADIC关键字就会触发错误。
• 查询写法：在WHERE条件中，使用WHERE column = ANY($1)。尽量避免写成IN (SELECT UNNEST($1))，后者会引入额外的子查询计划开销。

MySQL 8.0用JSON_CONTAINS做IN等价查询的陷阱

MySQL没有原生的数组参数支持，但在8.0及以上版本，可以用JSON_CONTAINS函数来模拟IN查询的行为。前提是，目标字段是标量值（比如user_id），并且JSON数组里的所有元素都是同一种类型。这里最常踩的坑是类型匹配问题：比如，把字符串形式的ID写成"1"（带引号），而数据库里的字段是INT类型，这会导致JSON_CONTAINS始终返回0（即不包含）。

另一个不容忽视的问题是性能。JSON_CONTAINS无法利用字段上的普通索引，在大数据量下，其性能可能比手动拼接一串OR条件还要差。因此，如果数组长度固定且非常短（比如不超过10个），有时候直接拼成WHERE id = ? OR id = ? OR ...反而更实在。

• 数组构造：使用JSON_ARRAY()函数来构造JSON数组，不要手动拼接字符串，以免引号或转义错误。
• 类型强制：比较时，使用CAST(json_unquote(JSON_EXTRACT(...)) AS UNSIGNED)来确保两边的类型一致。
• 前置校验：如果数组数据来自应用层，在传入查询前，最好先用JSON_VALID()函数校验一下JSON格式是否合法，否则JSON_CONTAINS可能直接报错导致查询中断。

说到底，实现动态IN查询，核心难点往往不在于“如何把参数传进去”，而在于“传进去之后，如何安全、高效地展开和使用”。用XML，得提防节点数量爆炸；用JSON，要小心类型匹配失准；而对于像PostgreSQL这样原生支持数组的语言，反而最容易在调用语法的细节上栽跟头。