通过不断查询PRIMARY_ID来监视数据库表是不是很糟糕＆gt; lastProcessedId

Question

我正在使用ElasticSearch（全文搜索）索引MySQL表。我们不是在创建时发送每个新行，而是每N秒（~30秒）对该表中的新记录执行一次SQL查询。我们通过存储最后处理的记录ID（auto_increment）并发出如下查询来执行此操作：

SELECT * FROM myTable where id > lastProcessedId

我的问题：这是处理这个问题的好方法吗？有任何严重的缺点吗？还有更好的选择吗？

我们还计划使用相同的方法来处理用户的喜欢（Facebook风格）。每N秒我们进行一次SQL查询以获取最新的“喜欢”，然后处理它们并更新每个用户的时间线。

我们正试图这样做以避免混淆旧的代码库。但是我对每秒发出这种类型的查询都不太满意，例如。

此解决方案的任何想法或问题？

Answer 1

听起来很贵，我会考虑其他方法。

1. 修改旧代码以插入插入内容！我知道它可能很吓人，但是那样糟糕吗？ ：）
2. 创建一个插入触发器，它会以某种方式启动重新索引过程，我认为你可以有很多选项来构建它。

结帐，http://www.roseindia.net/sql/trigger/mysql-trigger-after-insert.shtml

Answer 2

这有点贵，但坦率地说，如果它只是每30秒一次，我就这样做，直到它开始变得痛苦。

还有其他地方可以将数据稍后提取并处理，而不是通过数据库进行暂存。您可以使用一些简单的操作，例如将序列化副本附加到文件，每30-60秒写一个新文件，然后让脚本处理以前未处理的文件。同样，您可以将它们放入其他类型的队列中，然后根据需要随时运行。