mysql存储过程不支持数组参数，因其仅接受标量类型；可用json_contains()（5.7+）安全解析json数组，或用临时表+游标拆解字符串，find_in_set()性能差且限制多。
MySQL存储过程不支持数组或集合类型参数，这是由其底层设计决定的——它只接受标量（scalar）类型参数，比如 INT、VARCHAR、DATE 等单值类型。没有 ARRAY、LIST 或类似 PostgreSQL 的 INTEGER[] 这种原生类型。
MySQL 为什么连基本的数组参数都不支持
关系型数据库的 SQL 标准本身就不定义数组参数，MySQL 更是严格遵循“每参数一个值”的调用契约。存储过程的参数列表在编译期就固定了类型和个数，而数组长度可变、元素类型可能混杂，无法静态校验。这不是 bug，是设计取舍：优先保证类型安全与执行计划稳定性，而非灵活性。
你写 CALL proc(@arr)，MySQL 在解析阶段就要求 @arr 是某个确定类型的变量，不能是“可能包含多个值的东西”。哪怕你传入 '[1,2,3]'，它也只当它是 VARCHAR，不会自动解析结构。
FIND_IN_SET() 不是数组支持，只是字符串匹配陷阱
FIND_IN_SET() 常被误当作“数组支持方案”，但它本质是纯字符串函数：输入必须是逗号分隔、无空格、无引号、无嵌套的扁平字符串（如 '1,2,5'），且字段值会被隐式转成字符串比对。
- 遇到前导零（
'001'vs'1'）直接失配 - 字段是
INT类型时，全表扫描 + 函数计算，10 万行以上查询基本不可用 - 无法做
>、LIKE、IN (SELECT ...)这类操作，只能精确等于某一项 - 如果传入
'1, 2, 5'（带空格）或'"1","2","5"'，结果永远为 0
JSON_CONTAINS() 是 MySQL 5.7+ 的真实替代方案
真正接近数组语义的是 JSON 方式：把数组写成标准 JSON 字符串（如 '[1,2,5]' 或 '["a","b","c"]'），再用内置 JSON 函数解析。
关键点：
- 必须先校验：
JSON_VALID(@json_param)，否则非法 JSON 会让后续语句直接报错 - 匹配数字字段要用
CAST(id AS JSON)，否则类型不一致导致JSON_CONTAINS()返回FALSE - 匹配字符串字段得用
JSON_QUOTE(name)，否则name被当标识符、"name"才是字符串字面量 - 别在 WHERE 子句里反复调用
JSON_EXTRACT(@arr, '$[0]')—— 先SET @first = JSON_EXTRACT(...)缓存
低版本（MySQL
没有 JSON 函数？那就得手动把字符串“掰开”存进临时表，再关联或游标处理。常见坑有：
-
SUBSTRING_INDEX()嵌套写法易出错，比如SUBSTRING_INDEX(SUBSTRING_INDEX(str,',',n),',',-1)，n 超出实际项数会返回整个剩余字符串 - 循环中没控制好
i初始值或递增逻辑，容易死循环或漏项 - 临时表没加
DROP TEMPORARY TABLE IF EXISTS，重复调用会报“表已存在” - 游标声明必须在所有
DECLARE变量之后、任何可执行语句之前，顺序错就编译失败
最麻烦的其实是维护成本：每换一种分隔符、每多一层嵌套、每加一个字段类型，都要重写拆解逻辑。这不是“模拟数组”，是在给字符串写解析器。
