MySQL存储SHA1值调整字段长度仍报Data too long for column错误如何解决

核心问题排查 #

你修改表字段后仍然报错，大概率和表字段长度无关，优先排查以下几类常见原因：

• 存储过程入参长度限制（最高发）
  你仅调整了表的password字段长度，但未修改存储过程RegisterUser的入参定义。若该存储过程接收密码的第二个入参初始设置为varchar(20)，输入长度超出参数限制时会直接抛出报错，请求根本不会执行到写表步骤。
  排查命令：SHOW CREATE PROCEDURE RegisterUser;
  解决方法：修改存储过程，将对应密码入参的长度调整为varchar(40)即可。

你使用的调用语句本身参数合法，传入的SHA1值EF548F8AC757FAE6146574F365F64957F16D8A17确实为40位标准长度：
call RegisterUser("test2","EF548F8AC757FAE6146574F365F64957F16D8A17","test2","test2",@returncode);

• 表字段修改未生效
  可能存在修改了错误的库/表、DDL操作未提交的情况，可执行以下命令确认表字段实际配置：
  排查命令：DESC 你的用户表名;
  确认password字段类型确实为你修改后的varchar(40)/text等可容纳40位字符串的类型。
• 触发器关联字段限制
  若用户表配置了BEFORE INSERT/BEFORE UPDATE类触发器，存在将password字段值同步写入其他关联表/字段的逻辑，关联目标字段长度不足也会触发相同报错。
  排查命令：SHOW TRIGGERS LIKE '你的用户表名';
• 存储过程内部二次处理逻辑
  检查RegisterUser存储过程内部是否存在对密码参数的二次处理逻辑，比如拼接固定盐值、二次哈希等，若处理后生成的字符串长度超出表字段限制也会报错，可在存储过程中增加临时日志输出处理后的密码长度确认。

不推荐操作 #

不建议直接修改sql_mode为非严格模式，该操作会跳过数据长度校验，触发静默的数据截断，导致实际存入的密码哈希值不完整，后续所有登录校验都会失败，属于绕过问题而非解决问题的方案。

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