MySQL存储过程不支持原生数组参数，需用字符串或JSON模拟；FIND_IN_SET()仅适合小数据量调试，性能差；MySQL 5.7+推荐JSON_CONTAINS()，需校验JSON合法性并统一类型转换。
MySQL 存储过程原生不支持数组类型参数，所有“传数组”都是模拟行为。直接用 IN 参数传数组会报错，必须转成字符串或 JSON 再解析；选哪种方式，取决于你的 MySQL 版本、数据安全要求和查询性能预期。
FIND_IN_SET() 适合临时调试，但别在线上用
它能快速验证逻辑，但底层是全表扫描 + 字符串逐字符匹配，没有索引支持，数据量一过万就明显变慢。
- 输入字符串必须严格为
'1,2,5'格式：不能有空格、不能带引号、不能嵌套，'1, 2, 5'或'"1","2","5"'都会失败 - ID 字段是
INT类型时，MySQL 会隐式转成字符串比对，但'001'和'1'会被判为不同值 - 无法做范围查询（如
id BETWEEN 1 AND 10）或模糊匹配（如LIKE），只能精确等于某一项 - 示例写法（仅限小数据量测试）：
SELECT * FROM user WHERE FIND_IN_SET(id, '1,2,5');
MySQL 5.7+ 推荐用 JSON_CONTAINS() 解析 JSON 数组
传参用标准 JSON 格式（如 '[1,2,5]' 或 '["a","b","c"]'），函数校验严格、类型安全、可利用部分优化路径，是当前最稳的方案。
- 务必先校验 JSON 合法性：
JSON_VALID(@json_param)，避免非法输入导致后续语句中断 - 匹配整数字段时，要用
CAST(id AS JSON)统一类型，否则JSON_CONTAINS('[1]', 1)可能返回 false - 匹配字符串字段（如
name）时，必须用JSON_QUOTE(name)包裹，否则"alice"和alice被视为不同值 - 大数组（>100 项）别在
WHERE里反复调用JSON_EXTRACT()，先缓存：SET @arr = JSON_EXTRACT(@json_param, '$');
需要循环处理每个元素？优先用临时表，别硬写 WHILE
想对数组中每个 ID 做 INSERT 或 UPDATE？别在存储过程中手写 WHILE 拆串——容易漏边界、难调试、性能差。更可靠的做法是把字符串转成临时表，再用 JOIN 或子查询驱动。
- 低版本（SUBSTRING_INDEX + 自增变量插入临时表，但要注意
@num初始值和长度判断逻辑 - MySQL 8.0.4+ 直接用
JSON_TABLE()，语法清晰、类型安全、支持列别名，但低版本会报错FUNCTION JSON_TABLE does not exist - 示例（8.0.4+）：
SELECT id FROM JSON_TABLE('[1,2,5]', '$[*]' COLUMNS (id INT PATH '$')) AS jt; - 临时表记得加
DROP TEMPORARY TABLE IF EXISTS，避免重复调用时报错
真正容易被忽略的是参数类型和校验环节：很多人直接把应用层拼好的字符串塞进 IN 参数，没做 JSON_VALID() 或长度截断，结果线上查不到数据还找不到原因。JSON 方案看着多一步，实则省掉一半排障时间。
