MySQL存储过程执行动态字符串SQL查询报1064语法错误

你遇到的报错位置卡在第二条UPDATE语句开头的特征，90%以上概率是MySQL预处理语句不支持多语句同传的原生限制导致，剩余可能是字符串转义失效、拼接语法残留问题，具体排查和修复逻辑如下：

核心根因1：PREPARE原生不支持一次执行多条SQL #

• MySQL的PREPARE预处理机制设计上仅支持单条SQL语句解析执行，如果你通过fn_Sys_GenUpdateDetail生成的ls_query是用分号分隔的两条UPDATE语句，格式类似：

  UPDATE rm_sensor_combined SET subid = 0, rmip = '10.7.75.122', dname = 'ESD-xxx' WHERE rscuid=1;
  UPDATE rm_sensor_combined SET subid = x, rmip = 'x.x.x.x', dname = 'ESD-yyy' WHERE rscuid=2;
  

  那么PREPARE解析到第一条语句结尾的分号时就会认为语句结束，后续第二条UPDATE开头的内容会被判定为非法语法，报错位置刚好就会指向你看到的UPDATE rm_sensor_combined片段，和你给出的报错信息完全吻合。
• 快速验证方法：在存储过程里PREPARE stmt FROM @sql之前加一行SELECT @sql;，执行存储过程后会打印出完整的生成SQL，把内容复制到MySQL客户端手动执行就能直接确认问题。

核心根因2：字符串值未转义导致SQL截断 #

• 你给出的报错片段里，dname的取值到'ESD-就中断了，需要检查拼接逻辑里字符串字段的取值是否包含未转义的单引号：比如实际dname值是ESD-'设备1，拼接时没有做转义就会生成dname = 'ESD-'设备1'的片段，MySQL解析到ESD-后面的单引号就会判定字符串结束，后续内容直接触发语法错误。

核心根因3：拼接逻辑残留多余符号 #

• 检查函数生成SQL时是否在语句拼接处残留了多余的逗号、括号、存储过程自定义分隔符（比如$$、//），比如SET子句最后一个字段后面多拼了逗号，也会在对应位置抛出1064错误。

对应修复方案 #

1. 避免多语句同传：要么把两条UPDATE合并为单条语句，通过CASE WHEN匹配不同rscuid的更新值（参考下方示例），要么拆分生成的SQL字符串，循环对每条单语句单独做PREPARE、EXECUTE、DEALLOCATE操作。
   单条语句合并示例：

   UPDATE rm_sensor_combined
   SET
     subid = CASE rscuid WHEN 1 THEN 0 WHEN 2 THEN 对应2的subid值 END,
     rmip = CASE rscuid WHEN 1 THEN '10.7.75.122' WHEN 2 THEN '对应2的rmip值' END,
     dname = CASE rscuid WHEN 1 THEN 'ESD-对应1的后缀' WHEN 2 THEN 'ESD-对应2的后缀' END
   WHERE rscuid IN (1,2);
   

2. 规范字符串拼接：在自定义函数里拼接字符串类型字段值时，统一用QUOTE()函数包裹取值，自动处理单引号转义、特殊字符转义，避免字符串提前闭合截断。
3. 增加预校验：调试阶段先打印完整的生成SQL做人工校验，确认无拼接错误、截断问题后再执行预处理逻辑。

内容的提问来源于stack exchange，提问作者bfernKim