在什么情况下您会或不会使用数据库触发器而不是 cron 调用的脚本？
没有冗余数据的完全规范化数据库在“学术上”是好的，但在现实世界中的性能却很糟糕。
第一个优化显然是缓存系统。此后，为了创建冗余数据以提高性能，何时或为什么会（或不会）在调用脚本来更新冗余数据的 cron 任务上使用触发器？
A fully normalized database with no redundant data is good "academically", but has terrible real-world performance.
The first optimization is obviously a cache system. After this, for creating redundant data for performance, when or why would (or wouldn't) you use triggers over a cron task that calls a script to update the redundant data?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不是 MySQL 人员，但这个概念应该移植...
基本上，cron 作业是一个计划作业（无论您希望运行的频率如何），并且触发器...好吧...触发。一般来说，当您想要的任务是以下一项或两项时，您将使用任何类型的调度（Cron、计划作业（在 MS Sql 世界中）等）：
* 时间不敏感
* 流程密集。
对于任何对时间敏感且处理不密集的事情，您都可以使用触发器。
对于那些既对时间敏感又对流程密集的情况，您必须决定哪个更重要（或者在代码中的某个地方处理 SQL 之外的运算）。
Not a MySQL guy, but the concept should port...
Basically, a cron job is a scheduled job (however frequently you want that run), and a trigger is... well... triggered. In general, you would use any kind of scheduling (Cron, scheduled jobs (in the MS Sql world), etc.) when the task you want is one or both of:
* Not Time Sensitive
* Process Intensive.
For anything that is time sensitive and not process intensive, you'd use a trigger.
For those cases where something is both time sensitive and process intensive, you have to decide which is more important (or handle the crunching outside of SQL in code somewhere).