我必须在CRON上工作，它将在订阅的当天每周向订阅用户发送电子邮件。例如，如果用户A在周四订阅，用户B在周三订阅，则用户A将在每个周四收到邮件，用户B在每个周三收到邮件。
现在我的方法是：
1-首先获取当前（今天）日期的星期几并分配一个变量
2-运行SELECT查询并获取订阅日与今天日期相似的所有订户ID。我计划使用MYSQL的dayofweek（）从一周中提取一天，
3-一旦获得所有ID，然后通过电子邮件将最后7天的活动发送给这些订户。
让我有点困惑的是DAYOFWEEK（）函数，它基于列并且看起来很昂贵。你有什么建议？（假设表中有大量数据）
最佳答案
每行函数很少随着数据库表的增长而扩展。
你应该做的第一件事是确保确实有一个性能问题需要解决。总是从第三种正常形式开始，只有当你发现这样的问题时才回归，否则你的努力就白费了。可能是速度没有那么差，在这种情况下，坚持3NF。
如果发现存在性能问题，一种解决方法是添加名为week day的列并对其进行索引，该列将保存用户订阅的一周中的某一天。
这在技术上突破了3NF，因为该属性取决于订阅日期，而订阅日期不太可能是密钥的一部分。如果您独立更新一个或另一个，也可能会与订阅日期不一致。
但是，您可以通过使用insert/update触发器来缓解问题，该触发器强制weekday列与订阅日期一致，确保它们永远不会不一致。
然后，您的查询简单地变成如下内容：
dow = Now.dayOfWeek()
rowSet = executeQuery ("select sub_id from subscribers where weekday = ?", dow)
然后处理每个订阅者（如果你愿意的话，也可以作为一个大的honkin'query）。
您不必检索每一行来执行
getWeekDay (subscription_date)并筛选行，这一事实将大大提高查询速度。绝大多数数据库的读取频率远远高于写入频率，通过将计算成本转移到insert/update，可以有效地将该成本分摊到所有选择上。
假设你的订阅者订阅超过一周（因为你一周发一次他们的东西），这将比计算
select更有效。而且，虽然这会占用表中更多的空间（由于额外的列和索引），但是请查看“我的查询不够快”问题与“我的数据库太大”问题的比率。前者远远超过后者。