如果您需要使用near-real时间数据为用户提供服务，那么您应该采用第二种方法。它将更新solr索引中的数据，并且make可供用户搜索。
如果您不需要近乎实时的搜索用户，那么您应该采用第一种方法，即每30分钟更新一次索引。
但请记住，这些可能需要在solr设置中进行一些不同的配置。
由于younghobbit建议更深入地了解应用程序数据的类型，这使得回答更容易。
即使这样，我也会为我所知的一些要点进行布局，然后你可以做出更明智的选择。
- SOLR索引与事务处理数据库不同。它被设计为高效的原始文本内容搜索和内部它做了一些很好的东西来帮助搜索的速度（我不是SOLR内部的专家..所以SOLR专家请随时详细说明'好stuf'）。为搜索索引数据的过程并不是很便宜，因此最好让SOLR每X分钟而不是所有时间都进行索引。毕竟，您希望它使用大部分可用资源来为搜索提供最相关的结果。
- 您可以根据需要随时向SOLR发送数据，但只有在提交后才真正可用。您可以在每次操作后提交或让SOLR每隔x分钟执行一次自动提交。 （我不记得确切的配置，但我认为它的15分钟左右）。提交真正触发了资源饥饿的索引过程，因此做太多提交并不好。另一方面，提交太少将导致过时的索引。
- 由于您有一个MySQL数据库，我猜测有些记录也会更新。截至4.x SOLR内部SOLR实际上并没有更新文档。 SOLR处理更新的方式是将旧文档标记为已删除并简单地创建新文档。这意味着每次更新都会导致SOLR在磁盘上逐渐增加空间。您偶尔可以调用“优化”操作，SOLR将删除“已删除”文档。再次优化是资源匮乏，最好在服务器不太忙时完成。此外，Optimize会导致SOLR在优化期间耗尽更多磁盘空间（规则缩略图=索引大小* 2）。
想象一下，如果您的MySQL记录在30分钟内更新了10次，那么如果您在每个http帖子上向SOLR发送数据，那么这将导致在SOLR中删除9个和一个活动文档。而在30分钟的cron作业的情况下，它将意味着发布1个或最多2个记录。
- SOLR并不完全是交易性的。它具有提交和回滚操作，但它们适用于自上次提交以来添加的所有文档。 （建议阅读SOLR文档）。这与通常提交的http帖子不同，MySQL数据库上的回滚将在同一http请求的范围内。例如，你在每个http帖子上向SOLR发送数据，让我们说你遇到需要回滚的场景，MySQL会做一个干净的回滚，但是SOLR回滚是不可行的，因为它可能会回滚当前http帖子所做的其他更改处理正在进行中。
我个人认为方法1更好但你可能想要调整cron的频率以获得近乎实时的搜索响应。真正的实时只能通过方法2实现，但您必须考虑如何处理与SOLR相关的更新，事务。在选择任一选项之前，请充分了解SOLR中的提交，回滚和优化操作。