我们的 OutboxRecord 表在多个主机上遇到间歇性超时。这些超时发生在高负载或批处理期间之外，这使我们怀疑它们可能与大量记录或潜在的数据库锁定问题有关。 我们发现 OutboxRecord 表中的 TransportOperations 列可能变得非常大，从而导致严重的性能问题。 具体来说，我们正在考虑：
压缩：对 TransportOperations 列实施压缩，以减小大小并提高性能。 发件箱功能配置：验证和优化 NServiceBus V 7.X 中发件箱功能的配置 任何人都可以提供以下方面的指导或最佳实践：
高效处理TransportOperations列中的大数据？ 诊断和解决与 NServiceBus 相关的数据库锁定或超时问题的最佳实践？ 使用自定义行为对大型 TransportOperations 数据进行压缩的建议以及如何进行？
优化发件箱存储的最佳方法是不要包含大消息，因为数据库通常不会针对大块数据的高 I/O 进行优化。这可以使用声明检查模式来完成，或者通过使用 NServiceBus 数据总线功能，或者通过获取“大数据”并将其放在其他地方（文件共享、云 blob 存储），然后在消息中手动包含消息中大数据的位置/URL。
NServiceBus 论坛有关于这些主题的更多讨论。