选择 #1 将是最佳选择，创建一个要发送的电子邮件表，并在发送每封电子邮件时更新该表。最好不要删除条目而是将其标记为已发送，你永远不知道有一天你会遇到问题并想重新发送电子邮件，我已经在类似的设置中看到过很多次这种情况。
一个警告——在 web 应用程序中紧密耦合初始电子邮件的传输可能会导致架构脆弱（例如 SMTP 服务器不可用）——并丢失消息。
您可以通过 MSMQ 为初始电子邮件和提醒电子邮件引入抽象层 - 并让服务按计划清扫队列。初始消息可以用表示“立即发送”的属性进行标记 - 提醒消息可以标记为“已调度” - 扫地机只需发送它发现的任何“立即发送”或属于“立即发送”的消息"SCHEDULED" 并且有一个 toBeSentDate >= 当前日期。成功发送消息后 - 可以通过从队列中删除消息来结束工作单元。
这种方法可确保消息不会丢失 - 并通过调整服务轮询间隔将负载分配到非高峰时段。
正如 Rob Williams 指出的那样——我对 MSMQ 的建议对于这个特定问题来说有点矫枉过正......但当你开始考虑规模问题时，这是一种可行的方法——并且你希望（或需要）最小化/减少数据库读/写活动（尤其是在处理高峰期）。
给 Rob 的帽子小费。
对于每个较大的项目，我通常还会创建一个执行定期或定期任务的服务。
该服务在数据库中的某处更新其状态和上次执行的时间，以便应用程序可以使用该信息。
例如，应用程序将命令发布到命令队列，并且服务在计划时间处理它们。
我发现这个解决方案比 SQL Server 任务或作业更容易处理，因为它只是您需要安装的一个服务，而不是确保正确设置所有必需的作业。
此外，由于该服务是用 C# 编写的，因此我手头有一种比 T-SQL 更强大的编程语言（加上库）。
如果需要处理的确实是纯 T-SQL 内容，那么将有一个 Execute_Daily 存储过程，该服务将在日期更改时调用该存储过程。
正如其他人所建议的那样，创建一个单独的批处理服务，但使用它来发送所有电子邮件。
Web 应用程序应在数据库表中记录发送通知的需要，包括即时通知和提醒通知，这两个记录都标有所需的发送日期/时间。
使用 MSMQ 是多余的——您已经拥有了一个数据库和一个简单的应用程序。随着复杂性的增加，MSMQ 或类似的东西可能有助于提高复杂性和可伸缩性。
该服务应定期（每隔几分钟到几个小时）扫描数据库表以查找要在不久的将来发送的通知（电子邮件），发送它们，如果成功则将它们标记为已发送。您最终可以利用它来发送短信 (SMS) 或即时消息 (IM) 等。
当您使用它时，您应该考虑使用命令设计模式，并将此服务实现为可重用的命令执行器。我最近使用需要与第三方提供商保持房地产列表 (MLS) 数据同步的 Web 应用程序来完成此操作。
您的选项 2 看起来确实像是您正在发明的东西。我知道如果您要向我发送类似的邮件，我的邮件系统将不会保留邮件以供将来投递。
我认为你没有遗漏任何明显的东西。您将需要在约会当天运行的东西来发送电子邮件。将其作为 SQL 作业还是作为单独的应用程序会更好，这取决于您的应用程序架构。
我会推荐第一个选项，使用 SQL 或其他应用程序每天自动运行以发送电子邮件。这很简单，而且有效。
Microsoft Office 具有交付延迟功能，但我认为这是 Outlook 的事情，而不是 Exchange/Mail Server 的事情，因此您将不得不使用选项 1 或 3。或者选项 4 将是编写服务。这样您就不必担心计划任务来运行选项 3 应用程序。
如果您打算将此应用程序托管在便宜的托管服务（如 GoDaddy）上，那么我建议您在 Application_Start 的 Global.asax 中分离一个工作线程并让它休眠、唤醒、发送电子邮件、睡觉...
因为您将无法在 SQL Server 机器上运行某些东西，并且您将无法安装自己的服务。
我这样做，它工作正常。