sql server 用 sys.dm_exec_requests 关联 sys.dm_exec_sql_text 查实时 sp 状态，status 为 running/runnable/suspended 才算真执行；postgresql 用 pg_stat_activity.state='active' 结合 query 字段判断函数运行；mysql 需启用 performance_schema.events_statements_current 查 sp 当前行。
SQL Server 中如何获取正在运行的存储过程状态
直接查 sys.dm_exec_requests 和 sys.dm_exec_sql_text 是最可靠的方式，它能实时反映当前正在执行的 SP（包括阻塞、等待、CPU/IO 消耗），比轮询 sysprocesses 或依赖 sp_who2 更准确、更轻量。
- 必须关联
sql_handle才能拿到实际执行的 SQL 文本，否则只能看到EXEC proc_name这种外壳 -
status字段值为running/runnable/suspended才算“真正在跑”，sleeping是已结束但连接未释放，别误判为卡死 - 如果存储过程里用了
WAITFOR或大事务，wait_type会显示WAITFOR或LCK_M_*，这是正常行为，不是故障信号 - 避免在高并发 OLTP 环境中每秒轮询——建议最小间隔设为 5 秒，且加
WHERE command = 'EXECUTE'过滤掉其他操作
PostgreSQL 怎么监控函数执行状态
PostgreSQL 没有内置的“正在运行的函数”视图，得靠 pg_stat_activity + pg_blocking_pids() 组合判断，重点看 state、backend_start、state_change 三个字段。
-
state = 'active'表示后端正在执行某条语句，但不保证是函数——需检查query字段是否包含SELECT my_func()或CALL my_proc() - 函数内若调用
pg_sleep()，state仍为active，但wait_event_type会是Client或Timeout，不能单凭state判定卡死 - 注意
pg_stat_activity默认只对超级用户或同用户可见，普通监控账号需授权：GRANT SELECT ON pg_stat_activity TO monitor_role; - 不要依赖
backend_start推算执行时长——它记录的是连接建立时间，不是函数开始时间
MySQL 存储过程运行中怎么查卡在哪一行
MySQL 原生不支持行级执行点追踪，INFORMATION_SCHEMA.PROCESSLIST 只显示“正在执行存储过程”，但看不到具体语句位置。真正可行的是开启 performance_schema 并启用 events_statements_current 表。
- 必须提前开启：确保
performance_schema= ON，且setup_consumers中events_statements_current为ENABLED - 查当前活跃 SP 的真实语句：
SELECT SQL_TEXT FROM performance_schema.events_statements_current WHERE THREAD_ID IN (SELECT THREAD_ID FROM performance_schema.threads WHERE PROCESSLIST_INFO LIKE '%CALL%'); - 如果返回空，大概率是 SP 已执行完但连接未断开，或
performance_schema没捕获到（比如语句太短、被过滤） - 不要用
SHOW FULL PROCESSLIST查细节——它不显示函数体内的中间语句，只显示最外层 CALL
仪表盘实时刷新时容易漏掉短时过程
很多监控页面用 AJAX 每 10 秒拉一次数据，结果发现执行时间
- 短过程可能在两次请求之间完成，建议前端加本地缓存：把上一轮查到的
session_id/pid记下来，下轮对比is_active状态变化，补全“开始→结束”事件 - 服务端别只返回“当前快照”，可附加一个轻量聚合字段，比如
recently_completed_count（过去 30 秒内完成的 SP 数），靠sys.dm_exec_query_stats的last_execution_time推算 - 如果用 Prometheus + Exporter，注意
counter类型指标无法体现瞬时状态，得配合gauge类型暴露“当前运行中数量” - 别让前端自己算耗时——数据库返回的
start_time是服务器时间，前端时钟可能有偏差，所有耗时逻辑应在服务端计算并透出
最麻烦的其实是跨库一致性：SQL Server 的“运行中”、PostgreSQL 的“active”、MySQL 的“State: executing”，表面意思接近，实际语义差很远。做统一仪表盘时，先对齐定义，再写适配逻辑，别指望一套 SQL 走天下。
