数据库里刚插进去一条订单，新记ASP页面得立刻知道。录触这不是新记什么高深需求，但真动手做的录触时候，坑比想象的新记多。

最直接的录触做法是轮询。写个定时器，新记每隔几秒查一次 SELECT COUNT(*) FROM orders，录触数字变了就触发逻辑。新记简单粗暴，录触兼容性也好，新记Access、录触SQL Server、新记MySQL 都能跑。录触问题是新记延迟不可控，查得太勤数据库压力大，查得太慢业务等不起。我之前做过一个工单提醒，轮询间隔设了 5 秒，结果用户投诉说提交完要愣半天才跳提示。后来改成 2 秒，数据库 CPU 直接飙到 40%，就为了盯一张小表。

SQL Server 的话，SqlDependency 是个正经方案。它底层走的是 Service Broker，查询注册之后，数据一变，ASP.NET 这边就能收到回调。代码不算复杂：先 SqlDependency.Start(connStr)，然后挂一个 OnChange 事件，里面重新绑定查询、处理业务。听着挺美，但限制不少——查询必须是两段式表名，不能用 SELECT *，不能用聚合函数，权限配置也容易翻车。我见过有人折腾一下午，最后发现是数据库没启用 Service Broker，白忙活。

MySQL 没有原生的查询通知机制。有人用触发器写文件，ASP 那边监听文件变化，土是土了点，但能跑。更常见的做法是走消息队列，触发器往队列表里插一条记录，后台服务消费队列再通知前端。多了一层，可靠性上去了，复杂度也上去了。小项目真没必要。

说个实际案例。之前帮人改一个内部系统，SQL Server 2008，要求新工单插入后 3 秒内弹出提醒。一开始用轮询，1 秒一次，勉强达标但服务器叫苦。换成 SqlDependency 之后，延迟降到毫秒级，数据库压力几乎归零。代价是代码得重构——原来随便写的查询全得改成合规的，WITH(NOLOCK) 不能加，TOP 得配合 ORDER BY。改完那天我盯着输出窗口，看到 OnChange 第一次触发的时候，还真有点小激动。

ASP 这边接收通知之后，别急着在回调里干重活。回调线程不是页面线程，操作 Session、Response 会直接报错。稳妥的做法是往一个静态队列里塞个标记，页面上的 Timer 或者 UpdatePanel 去读这个标记，再决定要不要刷新。或者用 SignalR 推给浏览器，体验更顺滑。不过 SignalR 又是另一套东西了，小场景犯不上。

还有一点容易忽略：通知注册是一次性的。OnChange 触发之后，原来的 SqlDependency 就失效了，必须重新执行一遍查询、重新绑定。忘了这一步，系统只会提醒你一次，后面就哑了。我踩过这个坑，测试的时候好好的，上线第二天用户说没动静了，查了半天才发现是没重新注册。

到底选哪种？看场景。数据量小、实时性要求不高，轮询最省事。SQL Server 环境、愿意折腾配置，SqlDependency 是正路。跨数据库、要解耦，上消息队列。没有银弹，只有合不合适。我自己的习惯是：能轮询解决的就别上依赖，毕竟少一个故障点。真到了轮询扛不住的时候，再换方案也不迟。