如何有效地将数百到数千个操作记录到数据库中
我目前的情况是，几秒钟内可能会发生 1000 个操作，并且我需要将所有这些操作存储在数据库中。
我目前所做的是保留一个空闲计时器，一旦该计时器达到预定义的时间，我就会采取缓存的操作（自上次提交以来的操作 - 这只是一个简单的列表）并将这些操作提交到数据库。
UI 需要尽可能响应（呃？）。
除了将数据库日志记录推送到单独的线程之外，还有其他有关性能的建议可以帮助我吗？
I currently have a scenario where a 1000 actions could occur in a matter of seconds and I need to store all these actions in a database.
What I currently do is keep a idle timer, once this timer reaches a pre-defined time, I take the cached actions (actions since last commit - which is just a simple list) and commit those actions to the database.
The UI needs to be responsive as possible (duh?).
Other than pushing the database logging to a seperate thread, are there any other suggestions with regards to performance that anyone can help me out with?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
尝试使用具有异步日志记录包装器的第三方日志记录框架，例如 NLog 。
Try using 3rd party logging frameworks like NLog which have asynchronous logging wrapper.
当操作发生时，将操作记录到日志文件的尾部。这有两个好处。它的速度非常快，因此您的 UI 仍然具有响应能力，这意味着如果应用程序崩溃，操作也不会丢失。
然后有一个后台线程来执行文件中的操作并更新数据库。应用程序崩溃后，您可以重新启动，后台线程只需使用过去安全保存的操作进行更新。您甚至可以有一个单独的应用程序/进程/Windows 服务来执行后台更新，并让 UI 应用程序仅执行日志写入。
如果您确实必须避免单独的线程，那么您需要以非常小的批量执行数据库更新，以便它们尽可能快，并且在空闲时间处理。但这种方法总是较差，因为数据库操作与您的 UI 同步。因此您的 UI 在此期间会挂起。任何数据库问题（例如由于连接问题而导致的超时）都会导致 UI 失效。
Log the actions to the tail of a log file as the actions occur. This has two benefits. It is real fast and so your UI is still responsive and it means that if the application crashes the actions are not lost.
Then have a background thread that takes the actions in the file and updates the database. After your application crashes you can restart and the background thread simply updates with the actions that were safely saved in the past. You could even have a separate application/process/windows service that does the background update and have the UI application only perform log writing.
If you really must avoid a separate thread then you would need to perform the database udpates in very small batches, so they are as quick as possible, and in idle time processing. But this approach is always going to be inferior because the database operation becomes synchronous with your UI. So your UI hangs for the duration. Any database problem such as a timeout due to connectivity problems then kills the UI.