Mysql 触发器/事件与 Cronjob

Mysql trigger/events vs Cronjob(Mysql 触发器/事件与 Cronjob)

问题描述

我有一个拍卖网站，可让我的用户进行无限量的自动出价.

I have an auction website which let my users place an unlimited amount of autobiddings.

要监控这些自动出价，必须每秒检查一次数据库.

To monitor these autobiddings something has to check the database every second.

我的问题是，最好使用 mysql 触发事件，还是每分钟使用一个执行 60 秒循环 php 脚本的 cronjob.

My question is if it is better to use mysql trigger events or to user a cronjob every minute that executes a 60 sec looping php script.

如果我使用 mysql 触发事件，将会有数百个相互叠加的事件堆栈，并在不同的时间触发.这甚至可能吗??并且服务器负载不会变得很大.我在某处听说有计划的事件时数据库将被锁定.顺便说一句，我正在使用 innoDB 表.

If i use the mysql trigger events there will be hundreds of events stacks on eachother, and fired on different times. Is this even possible?? ANd isn't the server load goning to be enourmous. I heard somewhere that the database will be locked while there is a schedueled event. I am using innoDB tables btw.

我希望有人能阐明这个话题.

I hope some one can shed some light on this toppic.

问候！

推荐答案

您最好运行一个单独的脚本，该脚本永远运行并监视您的数据库.这样你就不需要cron了.也没有大量的触发器.

You'd best run a seperate script that runs eternally and watches your database. That way you won't need cron. Nor a massive amount of triggers.

但您可能需要重新考虑整个问题.没有必要每秒实际更新出价.当有人实际将他的浏览器指向拍卖或进行手动出价时，您只需填写过去 x 分钟/小时.如果都是自动出价，您可以轻松计算向前和向后.

But you might want to reconsider your entire question. It's not necessary to actually update the bids every second. You only need to fill in the past x minutes/hours when someone actually points his browser to an auction or makes a manual bid. If it's all autobids you can calculate forwards an backwards with ease.

这篇关于Mysql 触发器/事件与 Cronjob的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持编程学习网！