我为一家小型建筑公司创建了两个数据库应用程序之间的夜间同步，并使用数据库邮件设置了简单的通知，让一些人知道加载是否成功。现在他们看到此通知正在工作，我被要求在员工全天更改工作订单时向他们的客户提供状态更新。
我做了一些研究并了解 DB Mail 不是为这种类型的功能而设计的，但我认为频率足够小，不会成为问题。我估计每天有 50-200 封电子邮件。
我找不到任何关于 DB Mail 的实际限制的信息，并且想知道过去是否有人尝试过类似的事情，或者我是否可以被推向正确的方向以使用最佳实践发送这些电子邮件。
如果我们在这里谈论数百个，您绝对可以继续。访问数据库邮件 MSDN 页面。当前的设计（即SQL2000之后的任何东西）是专门为大型、高性能的企业实现而设计的。它建立在 Service Broker（SQL Server的消息队列总线）之上，它通过进程隔离、集群和故障转移提供异步处理和可伸缩性。一个警告是增加了事务日志压力，因为消息与其他一些实现不同，受 SQL Server 的 ACID 保护，这反过来又使您可以在发生故障时完全恢复队列。
如果您想知道在迁移到专用解决方案之前Service Broker可以处理什么，这里有一个很棒的MySpace 案例研究。最有趣的片段：
我们不想开始使用 Service Broker，除非我们可以证明它可以处理我们需要的消息级别，以支持 440 台数据库服务器上的数百万用户，”Stelzmuller 说。“当我们去实验室时，我们带来了自己的工作量，以确保测试质量。我们需要看看 Service Broker 是否可以处理每秒 4,000 条消息的负载。我们的测试发现它每秒可以处理超过 18,000 条消息。我们很高兴我们可以使用 Service Broker 构建我们的解决方案，而不是自己创建自定义解决方案。