SQL Server 的 ERROR_LINE() 返回的是错误抛出时批处理中的静态行号，而非真实出错语句位置；动态 SQL、解析失败等场景下该值常失准，须结合 ERROR_PROCEDURE() 与上下文人工比对，并辅以 PRINT @sql、Profiler 等手段定位。
SQL Server 的 ERROR_LINE() 返回的行号为什么不准
ERROR_LINE() 返回的是存储过程定义体内的行号，不是运行时实际出错语句的位置。比如动态 SQL EXEC(@sql) 报错，ERROR_LINE() 总指向这行，而非 @sql 里那条真实崩溃的 SELECT 或 INSERT。又或者表结构损坏、权限缺失导致执行在解析阶段就中断，ERROR_LINE() 可能返回 BEGIN TRY 上面某行——它记录的是“错误被抛出时所在批处理的静态位置”，不是“错误源头”。
实操建议：
- 别单独依赖
ERROR_LINE()定位，必须结合ERROR_PROCEDURE()和上下文代码段（前后 5–10 行）人工比对 - 对含
EXEC、sp_executesql的动态 SQL，务必在执行前加PRINT @sql或SELECT @sql AS debug_sql，复制到新窗口执行验证 - 开启 SQL Server Profiler，勾选
SQL:BatchStarting和Exception事件，按时间顺序看最后成功执行的是哪条 Batch，下一条 Exception 就是真凶
MySQL 存储过程中根本没 ERROR_LINE() 怎么办
MySQL 不提供类似 SQL Server 的行号函数，SHOW WARNINGS 也只报错误类型（如 ERROR 1064），不带位置信息。它靠的是“分段可验证”：把整个过程按逻辑块切开，让每一段都能独立创建、调用、观察输出。
实操建议：
- 用
DELIMITER $$把过程体拆成多个小段，例如每个IF ... END IF单独建为临时过程，逐个调用测试 - 执行完存储过程后立刻运行
SHOW WARNINGS;，它比错误码更具体，比如提示Truncated incorrect DOUBLE value: 'abc'，能反推哪条赋值语句出了问题 - 对动态 SQL，强制在
EXECUTE stmt前加SELECT @sql AS debug_sql;，复制结果到新会话执行——90% 的引号不闭合、字段名漏反引号问题都在这一步暴露
Oracle PL/SQL 中真正有用的行号来自 FORMAT_ERROR_BACKTRACE
SQLERRM 只返回 ORA-00001: unique constraint violated 这种笼统信息，而 DBMS_UTILITY.FORMAT_ERROR_BACKTRACE 才输出带精确行号的调用链，例如：
ORA-06512: at "SCOTT.PROC_INSERT", line 22 ORA-06512: at "SCOTT.PKG_UTILS", line 45
注意：这个函数必须放在 WHEN OTHERS 的第一行，任何前置操作（哪怕只是 INSERT INTO log_table）都会污染堆栈，导致返回的行号变成当前行而非原始出错点。
实操建议：
- 日志记录必须拼接：
SQLERRM || CHR(10) || DBMS_UTILITY.FORMAT_ERROR_BACKTRACE，缺一不可 - 不要在
FORMAT_ERROR_BACKTRACE后再写RAISE，否则堆栈重置，行号就丢了 - 如果用了
UTL_CALL_STACK（12c+），优先用它替代FORMAT_ERROR_BACKTRACE，它支持更细粒度的调用帧提取
PostgreSQL 的行号得靠 GET STACKED DIAGNOSTICS 提取
PostgreSQL 的 EXCEPTION 块里没有内置行号函数，但可以通过 GET STACKED DIAGNOSTICS 拿到 v_context，里面含调用栈和行号信息。不过它默认不包含当前语句位置，需配合 v_message 和 v_sqlstate 综合判断。
实操建议：
- 在
EXCEPTION块开头立即执行：GET STACKED DIAGNOSTICS v_context = PG_EXCEPTION_CONTEXT; -
v_context是多行字符串，典型内容为：PL/pgSQL function proc_insert line 12 at SQL statement，正则提取line \d+即可 - 不要试图在
EXCEPTION外再查行号——事务已标记为 aborted，后续任何查询都可能失败
ERROR_LINE() 是源码行，Oracle 的 FORMAT_ERROR_BACKTRACE 是运行时调用帧行，PostgreSQL 的 v_context 是 PL/pgSQL 函数内行，MySQL 则干脆不提供——你得自己切片验证。忽略这个差异，直接拿函数结果去改代码，大概率改错地方。 
