MySQL存储过程传入GUID列表供IN子句使用失效问题咨询

失效核心原因 #

直接将'guid1','guid2'格式的拼接字符串作为存储过程参数，再写WHERE user_id IN (传入参数)时，MySQL不会自动拆分参数内的多个值，只会把整个字符串识别为单个匹配项，根本不会按多个GUID去匹配，自然返回不符合预期的结果。

方案1：纯逗号分隔传参 + FIND_IN_SET匹配（实现成本最低） #

• 调整传入参数格式：去掉每个GUID外层的单引号，直接拼接成guid1,guid2,guid3的纯逗号分隔字符串传入，参数类型设为LONGTEXT，避免内容过长被截断。
• 存储过程内放弃IN写法，改用FIND_IN_SET做匹配，示例代码：

DELIMITER //
CREATE PROCEDURE `query_user_by_guids`(IN in_guid_list LONGTEXT)
BEGIN
    SELECT * FROM user_table 
    WHERE FIND_IN_SET(user_id, in_guid_list) > 0;
END //
DELIMITER ;

-- 调用示例
CALL query_user_by_guids('a1b2c3d4-1234-5678-90ab-cdef01234567,d4c3b2a1-4321-8765-ba09-fedcba765432');

• 适用场景：中小数据量（GUID数量在1万条以内），GUID本身不含英文逗号，完全适配该方案，改造成本极低。

方案2：预处理动态SQL拼接（兼容原生IN写法，性能更优） #

• 保留原有'guid1','guid2'的拼接传参格式，通过预处理动态拼接SQL实现IN子句查询，性能比FIND_IN_SET更好，可以正常命中user_id字段上的索引。
• 示例代码：

DELIMITER //
CREATE PROCEDURE `query_user_by_guids_dynamic`(IN in_guid_str LONGTEXT)
BEGIN
    SET @exec_sql = CONCAT('SELECT * FROM user_table WHERE user_id IN (', in_guid_str, ')');
    PREPARE stmt FROM @exec_sql;
    EXECUTE stmt;
    DEALLOCATE PREPARE stmt;
END //
DELIMITER ;

-- 调用示例，直接传原有拼好带单引号的字符串即可
CALL query_user_by_guids_dynamic("'a1b2c3d4-1234-5678-90ab-cdef01234567','d4c3b2a1-4321-8765-ba09-fedcba765432'");

• 注意事项：必须严格校验传入的GUID格式，GUID为固定的8-4-4-4-12位十六进制加横杠结构，校验通过后再拼接SQL，避免SQL注入风险。适合GUID数据量较大、需要命中索引的场景。

方案3：JSON数组传参（MySQL 8.0及以上版本最优方案） #

• 把GUID列表封装为JSON数组传入，通过JSON_TABLE把JSON数组拆为临时表做关联查询，无注入风险，大数据量下性能稳定。
• 示例代码：

DELIMITER //
CREATE PROCEDURE `query_user_by_guids_json`(IN in_guid_json JSON)
BEGIN
    SELECT u.* 
    FROM user_table u
    INNER JOIN JSON_TABLE(
        in_guid_json,
        '$[*]' COLUMNS(guid CHAR(36) PATH '$')
    ) t ON u.user_id = t.guid;
END //
DELIMITER ;

-- 调用示例，传JSON格式数组
CALL query_user_by_guids_json('["a1b2c3d4-1234-5678-90ab-cdef01234567","d4c3b2a1-4321-8765-ba09-fedcba765432"]');

• 优势：不存在SQL注入隐患，支持10万级以上的GUID传参，可以正常命中字段索引，是MySQL新版本下的规范实现。

避坑提醒 #

• 不要尝试自定义字符串拆分函数配合IN使用，自定义函数在MySQL里很难用到索引，性能远低于上述三种方案。
• 存储过程的参数字段不要用VARCHAR(255)这类短长度类型，单条GUID长度为36字符，1000条GUID加分隔符长度就超过40KB，直接用LONGTEXT类型避免内容截断。
• 用FIND_IN_SET方案时，不要给传入的GUID带多余空格，否则会导致匹配失败。

内容的提问来源于stack exchange，提问作者Low Chen Thye