基于SignalR与Azure SQL DB的实时推送高CPU占用问题问询

现有轮询方案优化（改造成本最低，可快速降低CPU占用） #

• 重构存储过程逻辑：移除存储过程内部的等待变更逻辑（比如WHILE循环等待新记录），把等待逻辑移到后端服务侧，存储过程仅实现单次增量查询，查询到变更就返回结果，无变更直接返回空，避免存储过程长时间占用SQL线程和连接资源，直接解决90秒长查询占CPU的核心问题。
• 优化变更查询效率：给需要监控的数据表增加自动更新的时间戳字段，默认值设为GETUTCDATE()，增删改操作时自动更新该字段；存储过程仅查询上次轮询时间之后的记录，避免全表扫描，查询时加WITH (NOLOCK)脏读标识，省略锁校验开销，实时推送场景下可容忍极小概率的不一致问题。
• 动态调整轮询策略：取消后端固定10分钟循环的硬逻辑，改为根据当前SignalR活跃连接数动态调整轮询间隔：无前端在线时直接暂停轮询，低峰期间隔拉到30-60秒，高峰期间隔最低可降到10秒，避免无意义的重复查询。
• 增加后端缓存中间层：用IMemoryCache存储最近一次查询到的最大变更ID/最新时间戳，每次发起轮询前先对比缓存值，无变更时直接跳过存储过程调用，进一步减少SQL请求量。

长期替代方案（CPU开销更低，稳定性更强） #

• 改用Azure SQL原生变更跟踪功能：该功能不需要依赖Service Broker，Azure SQL全版本支持，轻量性远高于自定义存储过程。你只需要在库级别和对应监控表开启变更跟踪，后端每次记录上次查询的变更版本号，调用内置的变更跟踪函数即可直接拿到增量增删改记录，整体SQL CPU开销可比自定义存储过程降低60%以上。
• 改为业务侧触发推送：如果你的业务系统操作目标数据表的入口是统一的，直接在所有涉及目标表增删改的业务逻辑执行完成后，主动触发SignalR推送，或者将变更事件写入内存队列/Redis队列，由独立的后台服务批量消费后推送给前端，完全不需要轮询SQL，SQL侧额外CPU开销直接降到0。
• 轻量触发器+队列表中转：如果业务入口太散无法统一加逻辑，给目标表加极简触发器，仅在数据变更时将对应记录ID写入一张只有主键ID字段的队列表，轮询时仅查询队列表是否有新ID，有新ID再拉取对应完整变更数据，队列表查询开销极低，也能大幅降低CPU占用。

内容的提问来源于stack exchange，提问作者Shubham