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 走天下。
评论(0)