mysql存储过程无参数长度限制，报错主因是callproc生成的用户变量名超64字符（error 3061）或体内varchar声明过短导致group_concat等操作静默截断，另有execute权限未授予procedure对象所致。
MySQL 存储过程本身没有“执行参数长度限制”，你遇到的报错几乎都来自两个具体场景：一个是 callproc 方法生成的内部用户变量名超长，另一个是存储过程体内变量定义或 GROUP_CONCAT 等函数导致的字符串截断。根本不是参数传入时被拦，而是后续处理环节踩了 MySQL 底层硬编码的坑。
callproc 生成的用户变量名超 64 字符触发 ERROR 3061
MySQLdb（及兼容库如 mysqlclient）调用 callproc 时，会为每个参数生成形如 _proc_name_0 的临时用户变量。这个变量名长度必须 ≤ 64 字符——这是 MySQL 源码里硬写的 NAME_CHAR_LEN 限制，无法绕过。
- 假设存储过程叫
get_user_profile_by_email_and_device_type_and_status（52 字符），加上前缀下划线和_0，就变成_get_user_profile_by_email_and_device_type_and_status_0（55 字符）——还安全；但再加一个参数或名字多几个单词，很容易破 64 - 错误现象是
User variable name '_xxx_0' is illegal，错误码3061，不是语法错，也不是权限错 - 你改 Python 层的任何配置、升级 mysqlclient 版本、调整
max_allowed_packet都无效，因为问题出在 MySQL 服务端校验阶段
存储过程体内变量声明长度不足导致隐式截断
过程体中用 DECLARE var_name VARCHAR(N) 定义的变量，如果后续用 GROUP_CONCAT 或拼接操作塞入超长内容，就会静默截断——不报错，但数据丢了一半。
- 例如
DECLARE ids VARCHAR(1000)，但循环中GROUP_CONCAT生成的字符串实际达 1500 字符，MySQL 只存前 1000 个字符 - 这种截断常导致逻辑错乱：比如递归查树时漏掉部分 ID，最终结果不全
-
VARCHAR最大可设到 65535 字节（受行长度限制约束），但要注意 utf8mb4 下 1 字符 = 4 字节，所以VARCHAR(16383)才接近理论极限
EXECUTE 权限没给到过程对象本身，误以为是“参数传不进去”
用户执行 CALL proc_name('very_long_string_param') 报 ERROR 1370 (42000): execute command denied，常被误读为“参数太长被拒”，其实是权限没授对。
- 必须用
GRANT EXECUTE ON PROCEDURE db_name.proc_name TO 'user'@'host'，缺PROCEDURE关键字就白干 -
SHOW GRANTS FOR 'user'@'host'里看不到带ON PROCEDURE的条目，基本就是它 - 即使权限给了，若过程定义含
SQL SECURITY DEFINER，而DEFINER用户已被删或失权，也会报同样错误——和参数长度无关
真正卡住你的，往往不是“参数太长”，而是变量名生成规则撞上 64 字符铁律，或是体内变量声明太保守。别急着改应用代码，先看错误码、查 SHOW CREATE PROCEDURE、确认 GRANT 语句是否带 PROCEDURE——这些地方比调参容易出错得多。
