好的，这是场景。我有一个实用程序可以处理大量记录，并相应地将信息输入数据库。
它以多线程批处理的形式处理这些记录。每个这样的批次都写入同一个日志文件，以便为每个记录创建工作流跟踪。潜在地，我们可以在一天内进行接近一百万次的日志写入。
是否应该将此日志写入驻留在另一台服务器上的数据库中？注意事项：
两种方法都可以进行优化吗？
谢谢。
有趣的问题是，如果您决定登录数据库，您在哪里记录数据库连接错误？
如果我正在登录数据库，我总是有一个辅助日志位置（文件、事件日志等），以防出现通信错误。它确实使以后更容易诊断问题。
想到的一件事是，您可以让每个线程写入自己的日志文件，然后每天进行批处理以组合它们。
如果您正在登录到数据库，您可能需要进行一些调整和优化，特别是如果数据库将通过网络。至少您需要重用数据库连接。
此外，您是否有任何特定的需要登录数据库？如果您只需要一个“grep”，那么我认为您通过登录数据库不会获得太多收益。
我在这里支持其他答案，这取决于您对数据所做的事情。
我们这里有两种情况：
大部分日志记录到数据库，因为我们构建的产品的管理员用户需要能够在他们漂亮的小应用程序中查看他们所有的花里胡哨。
我们将所有诊断和调试信息记录到文件中。我们不需要真正“美化”它和 TBH，我们甚至不需要它，所以我们只记录和存档大部分。
我会说如果用户正在用它做任何事情，然后登录到数据库，如果它适合你，那么一个文件可能就足够了。
不确定它是否有帮助，但还有一个名为Microsoft LogParser的实用程序，据说您可以使用它来解析基于文本的日志文件并将它们用作数据库。从网站：
日志解析器是一个强大的多功能工具，它提供对基于文本的数据（如日志文件、XML 文件和 CSV 文件）以及 Windows® 操作系统上的关键数据源（如事件日志、注册表、文件系统和 Active Directory®。您告诉 Log Parser 您需要什么信息以及您希望如何处理它。您的查询结果可以在基于文本的输出中自定义格式，或者它们可以持久保存到更专业的目标，如 SQL、SYSLOG 或图表。大多数软件旨在完成数量有限的特定任务。Log Parser 是不同的......它可以使用的方式数量仅受用户的需求和想象力的限制。世界就是您使用 Log Parser 的数据库。
我自己没有使用过这个程序，但它看起来很有趣！
或者如何登录到队列？这样你就可以在你想登录不同的东西时切换轮询器。它使滚动和归档日志文件等事情变得非常容易。这也很好，因为您可以添加记录不同事物的轮询器，例如：
数据库-因为您提到了多个线程。同步和过滤检索是我回答的原因。
在决定切换到文件“Knuth：过早的优化是万恶之源”之前，看看您是否有性能问题，
我在那本书中没有进一步了解...... :)
有一些方法可以解决文件日志记录的限制。
您始终可以使用某种线程 id 开始每个日志条目，然后 grep 出各个线程 id。或为每个线程使用不同的日志文件。
我过去曾在一个单独的线程中以较低的优先级登录到数据库。我必须说，当您试图找出问题所在时，可查询性非常有价值。
记录到数据库文件怎么样，比如 SQLite 数据库？我认为它可以处理多线程写入——尽管这也可能有其自身的性能开销。
我认为这在很大程度上取决于您之后对日志文件所做的事情。
在写入日志文件的两个操作中，速度会更快——尤其是当您建议写入另一台服务器上的数据库时。
但是，如果您随后尝试定期处理和搜索日志文件，那么执行此操作的最佳位置是数据库。
如果您使用像 log4net 这样的日志框架，它们通常会提供简单的基于配置文件的方法来将输入重定向到文件或数据库。
我喜欢盖乌斯的回答。将所有日志语句放在线程安全队列中，然后从那里处理它们。对于 DB，您可以将它们批量处理，比如一批 100 个日志语句，对于文件，您可以在它们进入队列时将它们流式传输到文件中。
文件还是数据库？正如许多其他人所说；这取决于您需要日志文件的目的。