我想弄清楚 sp_send_dbmail 的最佳使用实践，但我在网上找不到任何答案。
我们的开发人员喜欢使用 sp_send_dbmail 从应用程序中发送与应用程序相关的电子邮件。假设用户忘记了密码，他们将通过执行 sp_send_dbmail 发送用户请求的密码重置电子邮件。这只是他们使用此存储过程发送的多种类型的电子邮件之一。这是一个好习惯吗？对我来说，这感觉像是一个肮脏的解决方案，因为有许多 API 可以处理应用程序中的电子邮件发送，而作为 DBA，我不喜欢在生产服务器上启用这些选项。我只是别无选择。也许有足够的动机和证据证明这是不好的做法和/或由于各种原因可能存在危险，我可以说服他们改变它。
SQL Server 核心许可证价格昂贵：使用 SQL Server 计算机的 CPU 发送数千封电子邮件是没有道理的，尤其是在功能、可管理性、设置和故障排除方面有无数更好的选择时。
另一点是电子邮件和数据库功能之间的紧密耦合使得应用程序难以扩展、隔离和管理。一台服务器 - 一项服务。
在我看来，数据库邮件应仅用于管理目的（警报），而不应用于发送商业电子邮件。
我没有看到问题。SQL Server 一直希望将业务逻辑包装到数据库中，无论是过程、纯 CLR 代码、报表、现在的分析，甚至是旧的服务代理。
有邮件在那里也不是那么糟糕。它以可查询的格式直接在数据库中提供出色的排队和交付历史记录。
除非您知道当前的特定漏洞，否则没有理由尝试将其删除。当然，你的时间还有更好的事情要做，而且不树敌，你实际上是在乞求他们用一个糟糕的解决方案来代替它，然后把责任归咎于你。我不会。
恕我直言，这不是技术问题。这是一个职业问题和学习时的阻碍。
尝试用新的方面来补充现有的答案：
如果
sp_send_dbmail使用，您将永远无法取消该数据库服务器的 Internet 访问权限。此外，这是一个安全问题，因为像 SMTP 这样的网络协议是漏洞的常见来源。应用程序最终用户现在可以让您的 SQL Server 通过 SMTP 连接到他们控制的主机（因为他们可能输入了电子邮件地址）。如果该主机回复 1TB 垃圾数据怎么办？SQL Server 可以处理吗？谁知道。
sp_send_dbmail是一个旧组件。也许它是试图解析网络数据的旧的、糟糕的 C 代码。我还认为，使用另一种语言发送邮件符合开发人员的最佳利益。T-SQL 不是用于过程任务的高效语言。
他们可能喜欢以下替代方案：让他们将邮件插入到数据库中的队列表中。然后，让应用程序定期轮询该表并从应用程序代码发送邮件。这样他们甚至可以以事务一致的方式发送邮件！这是非常方便的。这也很容易扩展。您可以使用 Service Broker 来减少轮询的需要。