mysql存储过程不自动转义特殊字符，调用时含未转义单引号（如'o'reilly'）会触发error 1064语法错误，必须由应用层转义为'o''reilly'或使用参数化查询；过程内可用replace预处理，但无法挽救语法解析阶段失败。
MySQL存储过程本身不自动转义特殊字符，解析含单引号、反斜线、换行符等的长字符串时，CONCAT 或直接拼接会出错或截断——必须在入参前转义，或在过程中用 REPLACE 预处理。
传入含单引号/双引号的字符串会报错
MySQL 存储过程调用时，如果外部传入的字符串里有未转义的单引号（比如 'O'Reilly'），客户端 SQL 解析器会在到达存储过程前就报 ERROR 1064。这不是存储过程的问题，而是 SQL 字面量语法层面的失败。
- 错误现象：
CALL parse_str('O'Reilly book');直接报错，根本进不了过程体 - 正确做法：调用时必须由应用层或 SQL 客户端做一次转义，例如写成
CALL parse_str('O''Reilly book');（两个单引号）或使用参数化查询（推荐） - 若无法控制调用方，可在过程开头用
REPLACE补救，但仅对已成功进入过程的字符串有效，不能挽救语法错误
在过程内安全拆分含逗号/分号的长字符串
用 LOCATE + SUBSTRING_INDEX 拆分时，若原始字符串含未转义的分隔符（如 'a,b,"c,d",e'），按逗号硬切会错乱。MySQL 没有原生 CSV 解析函数，需手动规避。
- 最简方案：约定分隔符不可出现在数据中（如用
\x01替代逗号），调用前由应用层替换 - 若必须支持嵌套引号，需在过程里加状态机逻辑：逐字符扫描，跳过引号内的分隔符——但性能差、易出错，不建议在存储过程中实现
- 更可靠的做法：把解析逻辑上推到应用层，存储过程只接收已拆好的单值列表（如临时表或 JSON 数组）
- 示例安全拆分（假设分隔符是
;，且数据不含未转义分号）：SET @str = 'val1;val2;val3';<br>SET @pos = 1;<br>WHILE @pos SET @next_semi = LOCATE(';', @str, @pos);<br> IF @next_semi = 0 THEN<br> INSERT INTO temp_values VALUES (SUBSTRING(@str, @pos));<br> LEAVE;<br> END IF;<br> INSERT INTO temp_values VALUES (SUBSTRING(@str, @pos, @next_semi - @pos));<br> SET @pos = @next_semi + 1;<br>END WHILE;
TEXT/LONGTEXT 字段存入时换行符丢失或乱码
即使字符串成功传入存储过程，插入 TEXT 或 LONGTEXT 字段后，\n、\r 可能显示为空格或被过滤——根源通常是表/列字符集不是 utf8mb4，或连接层未设 SET NAMES utf8mb4。
- 检查当前连接编码：
SELECT @@character_set_client, @@collation_connection;，应为utf8mb4 - 建表时显式指定：
CREATE TABLE t (content LONGTEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci); - 过程内拼接含换行的字符串，别用
CONCAT('a', '\n', 'b')—— MySQL 默认不识别 C 风格转义，得写CONCAT('a', CHAR(10), 'b') - 若从外部传入已含
\n的字符串，确保客户端发送时未被二次转义（如 PHP 的mysqli_real_escape_string会处理，但addslashes不适用）
真正棘手的不是“怎么写过程”，而是谁该负责转义和校验：存储过程适合做确定性、无歧义的字符串切片，不适合做带语义的解析（比如识别引号包裹的字段）。把复杂格式的清洗和预处理留在应用层，会让过程更稳定、更容易调试。
