实时监控数据库变化判断新数据，最简单的方法是给每条数据加一个时间戳或序号字段，比如插入时间或自增ID，每次检查时对比上次的最大时间戳或ID，比它大的就是新数据。对比轮询和监听，监听更高效，因为轮询需要不断问数据库有没有变化，浪费资源和时间；监听是数据库主动通知你有变化，只在真正有变化时触发，省时省力，适合实时性要求高的场景。

轮询 vs 监听的实际对比

我们项目里一开始用轮询，每5秒查一次数据库的最后更新时间，看有没有比上次记录的晚的记录。这样判断新数据很简单，就是 where update_time > last_check_time。但问题是，服务器CPU和数据库负载高了，5秒一次就很吃力，改成10秒网络延迟又大了。后来改用MySQL的binlog监听，数据库有变化就实时推送到Kafka，消费者订阅后直接处理新数据。效率提升了10倍，延迟从秒级到毫秒级，轮询完全不是对手。

判断新数据的几种方式

判断新数据有三种常见招：1. 时间戳法，新表加created_at字段，监控时select max(created_at) from table where created_at > ?；2. 版本号法，每行数据有个version字段，增量时version+1，监控对比version；3. 主键自增法，直接记录上次最大ID，下次select * from table where id > last_id order by id。时间戳最准，因为ID可能有删除导致空洞，但轮询这些方法都行，监听就不需要了，直接全量变化事件。

监听的具体实现分享

用Debezium监听数据库变化超级方便，它连上MySQL的binlog，就能把insert/update/delete事件实时发出来。你收到事件后，判断是新数据就入库或处理。比轮询高效多了，轮询像傻子一样不停问'有吗有吗'，监听是数据库喊'来了来了'。我们用在电商订单监控，轮询时QPS上千，现在监听QPS不到10，效果一样好。

轮询的优化和局限

轮询判断新数据可以用增量查询，比如上次max(id)=1000，这次where id>1000 limit 1000。但频繁轮询还是低效，尤其数据量大时，网络抖动一下就延迟。监听如Redis的Keyspace通知或数据库触发器push，零轮询零延迟。我们测试过，轮询1分钟平均50次空查询，监听零空查询，资源利用率高太多。

实际项目切换经验

老系统轮询监控用户注册表，新用户用where reg_time > last_time。切换到PostgreSQL的逻辑复制监听，变化直接通过wal发送，代码改动小，判断新数据变成if event.op == 'c' (create)，超级直观。效率对比：轮询高峰期数据库压力20%，监听1%，实时性从5s到50ms，强烈推荐监听。

FAQ

Q: 监听数据库变化需要额外工具吗？

A: 需要，像Canal、Debezium或Maxwell这些开源工具，免费好用，配置一下就能监听binlog。

Q: 小数据量轮询行不行？

A: 小量可以，简单无脑，但数据大了或实时要求高，就换监听吧。

Q: 判断新数据时间戳准吗？

A: 很准，但时钟不同步可能有问题，用数据库内置时间函数如NOW()更稳。

Q: 监听支持哪些数据库？

A: MySQL、PostgreSQL、Oracle大多支持，选工具看文档。