SQL Server用RAISERROR WITH NOWAIT实时推送进度消息；PostgreSQL依赖RAISE NOTICE配合客户端轮询和日志表；MySQL靠临时表+外部轮询；三者均需将进度日志单独提交，避免与业务事务绑定。
SQL Server 中用 RAISERROR 实现进度反馈
SQL Server 存储过程中无法直接返回“进度百分比”，但可以用 RAISERROR 配合 WITH NOWAIT 实时把消息推送到客户端，模拟进度条效果。关键不是“返回值”，而是“即时可见”。
常见错误是只写 PRINT——它会缓存输出，直到批处理结束才显示，完全起不到监控作用。
-
RAISERROR('Step 3/10: Updating orders...', 0, 1) WITH NOWAIT是有效写法；级别设为 0–10 表示非错误信息，不会中断执行 - 避免在循环中高频调用（比如每行都发一条），否则拖慢性能；建议按批次（如每 1000 行）或关键节点（如完成某张表处理）触发
- 某些客户端工具（如 SQL Server Management Studio）需开启“查询→选项→结果→连接→将 SET NOCOUNT 设为 OFF”才能稳定捕获
RAISERROR消息
PostgreSQL 中靠 RAISE NOTICE + 客户端轮询
PostgreSQL 没有 WITH NOWAIT 等效机制，RAISE NOTICE 的输出取决于客户端是否实时拉取——psql 默认实时，但 JDBC、ODBC 等驱动常需显式启用异步通知或分块获取。
典型场景是长事务中更新百万级数据，想让调度系统知道“还没卡死”。这时不能只依赖日志打印，得配合外部状态记录。
- 在关键步骤插入一条到日志表：
INSERT INTO proc_log (proc_name, step, ts) VALUES ('refresh_report', 'step_2_filter', NOW()) - 用
RAISE NOTICE 'Progress: % rows processed', v_count;辅助人工排查，但不作为自动化监控唯一依据 - 若用 pgAdmin，需确认“查询工具→选项→查询→自动刷新通知消息”已勾选；否则 NOTICE 可能被静默丢弃
MySQL 存储过程里没有原生进度机制，只能靠临时表+轮询
MySQL 8.0 之前连 RAISE 都不支持，5.7 及更早版本必须用 SELECT 或写临时表来暴露进度。这不是优雅方案，而是现实妥协。
例如一个分页更新过程，你想让外部脚本知道“已处理到第几页”，就不能只靠日志文件——因为日志是异步刷盘的，且不易结构化读取。
- 建一张进度跟踪表：
CREATE TEMPORARY TABLE IF NOT EXISTS _proc_status (key VARCHAR(64), val TEXT, updated_ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP) - 在循环中定期更新：
REPLACE INTO _proc_status VALUES ('batch_id', CONCAT('batch_', v_batch_no), NOW()); - 外部程序（Python/Shell）可定时查这张表：
SELECT val FROM _proc_status WHERE key = 'batch_id';，注意临时表只对当前会话可见，跨会话要用普通表+唯一 proc_id 标识
所有数据库共通陷阱：别把日志写进事务主体
进度日志本身不该和业务数据绑定在同一个事务里——否则回滚时日志也被撤销，你根本不知道它到底执行到哪一步就失败了。
最容易被忽略的是 PostgreSQL 的 COMMIT 和 MySQL 的 autocommit=0 场景下，忘记把日志操作单独提交。
- SQL Server：用
EXEC sp_executesql N'INSERT INTO audit_log ...'; COMMIT;单独提交日志语句 - PostgreSQL：在日志写入后加
COMMIT;（前提是没在大事务中），或改用dblink异步发日志 - MySQL：确保日志表是
InnoDB且单独START TRANSACTION; INSERT ...; COMMIT;，不要和主逻辑共用START TRANSACTION
进度监控的本质不是“炫技”，是让失败可追溯、等待有预期。真正在意进度的人，往往已经踩过三次“以为写进去了，其实没看到”的坑。
