生产环境存储过程执行失败主因是运行时环境差异，根因90%以上为权限、依赖对象状态、事务上下文或数据库方言兼容性问题。
生产环境存储过程执行失败，通常不是代码本身写错了，而是运行时环境与开发/测试环境存在关键差异。直接看错误日志里最靠前的那条 ORA-、ERROR 1422 或 function does not exist 就能定位根因——90% 以上的问题出在权限、依赖对象状态、事务上下文或数据库方言兼容性上。
查不到 sys.dm_exec_requests 中的目标过程？先确认是否真在跑
SQL Server 下用 sys.dm_exec_requests 查过程是否运行，必须同时满足三个条件：
-
status是running、runnable或suspended（sleeping表示已执行完但连接没关） -
session_id > 50（过滤掉系统内部线程） - 必须用
CROSS APPLY sys.dm_exec_sql_text(sql_handle)拿到实际调用语句，再用LIKE '%proc_name%'匹配——不能只信command = 'EXECUTE'
查不到结果的常见原因：sql_handle 失效（执行计划被清空）、账号没 VIEW SERVER STATE 权限、或过程刚执行完就退出了。
MySQL 触发器里报 ERROR 1442？别碰正在被触发的表
这是 MySQL 的硬限制：在 t1 的触发器中，禁止对 t1 执行任何修改操作（INSERT/UPDATE/DELETE），哪怕改的是其他行也不行。错误信息 Can't update table 't1' in stored function/trigger 就是这个意思。
绕过方式只有两种：
- 把原逻辑拆成异步任务（如写入 Kafka，由下游消费处理）
- 改用应用层逻辑替代——触发器只记录事件，不执行业务更新
注意：子查询里 SELECT ... INTO @var 如果没结果，@var 会变成 NULL，后续判断直接失效，这也常被误判为 ERROR 1442。
KingbaseES V9 中 NVL 或 DECODE 报错？默认不兼容 Oracle 方言
KingbaseES V9 默认按 PostgreSQL 语义解析 SQL，NVL、DECODE、ROWNUM 这类 Oracle 特有函数不会自动映射。报 function does not exist 是正常现象。
解决方法分场景：
- 迁移初期：启用兼容模式，在连接串加
options=-c%20kingbase_compatibility_mode=oracle（需服务端开启支持） - 长期维护：显式替换为标准函数，比如
NVL(a,b)→COALESCE(a,b)，DECODE(x,1,'a',2,'b')→CASE WHEN x=1 THEN 'a' WHEN x=2 THEN 'b' END - 避免用
LIMIT分页：KingbaseES V9 的 Oracle 兼容模式下仍不支持，得改用OFFSET ... FETCH NEXT
字符集混用（如源库是 GBK，KingbaseES 实例是 UTF8）也会导致触发器内字符串比较失败，但错误表现常被掩盖成逻辑异常而非明确报错。
Oracle 存储过程中 ORA-06550 编译失败？重点盯变量声明和异常块
ORA-06550 是 PL/SQL 编译期错误，真正有用的是它后面紧跟的行号和 PLS- 开头的子错误码（如 PLS-00302: component 'XXX' must be declared）。高频原因有三个：
- 变量未声明就使用：尤其在嵌套
BEGIN...END块里，外层声明的变量不可见 - 引用了已删除或权限不足的对象（如视图、序列），
SELECT seq.NEXTVAL INTO v_id FROM DUAL会因序列不存在直接报错 -
EXCEPTION块缺失或WHEN OTHERS后没RAISE，导致错误被静默吞掉，只留下上层调用失败
调试建议：把过程拆成最小可执行单元，在 SQL*Plus 里逐段 EXEC 测试；别依赖 IDE 的语法高亮——它不校验对象是否存在。
