服务器迁移后MySQL存储过程调用无效果且无报错求助

• 检查事务提交状态
  迁移后事务配置可能发生变化，若应用开启事务但未执行COMMIT，存储过程的操作会被回滚：

  • 查看mysql.log中存储过程调用语句后是否跟随COMMIT指令；
  • 登录数据库执行SELECT @@autocommit;确认自动提交状态；
  • 可临时在存储过程末尾添加COMMIT;测试，或检查应用代码中的事务处理逻辑是否在迁移后被修改。

• 验证执行上下文与数据库匹配
  确认应用连接的数据库是否为存储过程所在的qamphi库：

  • 核对应用连接配置中的数据库名称；
  • 手动执行带库名的调用语句：CALL qamphi.deleteUpdateOrder(468, 1);，观察数据变化。

• 排查存储过程DEFINER权限问题
  存储过程的DEFINER为tice@%，若该用户在新服务器不存在或权限不足，会导致存储过程内部操作静默失败：

  • 确认tice用户存在且拥有qamphi.questions表的DELETE、UPDATE权限；
  • 尝试修改存储过程DEFINER为当前应用用户：

    ALTER DEFINER=`qamphi`@`localhost` PROCEDURE `deleteUpdateOrder`(IN `s_id` INT, IN `deleted_q_order` INT)
    BEGIN
        DELETE FROM questions WHERE session_id=s_id AND q_order=deleted_q_order;
        UPDATE questions
            SET q_order = q_order-1
        WHERE q_order > deleted_q_order
        AND session_id=s_id;
    END
    

• 手动测试存储过程与数据存在性
  用qamphi用户登录数据库，执行以下操作排查：

  1. 查询目标数据是否存在：SELECT * FROM questions WHERE session_id=468;
  2. 执行存储过程：CALL deleteUpdateOrder(468, 1);
  3. 再次查询数据，观察变化并留意报错。
     若手动执行也无变化，可能是参数对应的记录本身不存在，导致DELETE和UPDATE无匹配行。

• 查看更详细的MySQL日志
  普通query log可能不记录存储过程内部错误，需检查：

  • MySQL的error.log，排查权限、语法或执行相关的隐性错误；
  • 临时开启general log，记录完整执行流程，捕获未显现的异常。

• 对比新旧服务器的sql_mode配置
  新服务器的sql_mode若与旧服务器差异较大，可能导致操作静默失败：

  • 在新旧服务器分别执行SELECT @@sql_mode;，对比配置差异；
  • 若新服务器开启严格模式（如STRICT_TRANS_TABLES），检查是否存在数据类型不匹配或约束冲突。

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