Событие Cronjob или MySQL?

Ответ 1

Я всегда буду выполнять задание cron, потому что:

• То, что системные администраторы ожидают, что это будет (этот момент нельзя недооценивать)
• crobtab пуленепробиваемый, проверенный временем, чрезвычайно широко используемый и понятный
• Вы можете свободно направлять/анализировать сообщения об ошибках/успехах, в которых вы хотите
• Некоторые задачи базы данных требуют/предпочитают mysql быть автономными (например, полная резервная копия), поэтому вы должны использовать cron для них - это плохая идея для выполнения некоторых задач с cron, а некоторые - с mysql; вы будете не уверены, где искать.
• Вы можете связать другие события, которые должны следовать, если у вас есть оболочка script

И, наконец, только потому, что вы можете что-то сделать, это не значит, что это хорошая идея. Mysql хорош в материалах данных. Не используйте его для "оболочки".

Ответ 2

Планировщик событий MySQL - хорошая замена для cron.

Мы все знаем о cron, простой способ запланировать определенные процессы, например, каждую неделю обрезать ваши таблицы журналов в вашей базе данных MySQL.

С MySQL 5.1 ребята из MySQL представили новую интересную функцию: Планировщик событий MySQL!

С помощью Планировщика событий вы можете планировать задачи, которые вы хотите выполнить в своей базе данных. Это отлично подходит для веб-разработчиков, которые не могут создавать задания cron на своем веб-пространстве, потому что их хозяин не позволит им! Это действительно отличная замена для cron!

Несколько примеров:

вы хотите каждую неделю обрезать таблицу журналов приложений, так должно выглядеть ваше расписание событий:

CREATE EVENT PurgeLogTable
ON SCHEDULE EVERY 1 WEEK
DO
BEGIN
DELETE FROM `logs` WHERE `LogTime` <= DATE_SUB(CURRENT_TIMESTAMP,INTERVAL 1 WEEK);
INSERT INTO `audit` (`AuditDate`, `Message`) VALUES(NOW(), "Log table purged succesfully!");
END

Ответ 3

Mysql представляет Event-планировщик, который мы можем использовать вместо Cronjob. Есть много преимуществ перед cronjob:

1) Он написан непосредственно на сервере Mysql.

2) Это независимая от платформы. Ваша заявка может быть написана на любом языке, это не имеет значения. Вам просто нужно знать mysql.

3) Мы можем использовать их всякий раз, когда требуется обновление или очистка базы данных, требуемая в интервале regulare.

4) Не нужно собирать запросы каждый раз, чтобы увеличить производительность.

5) Ошибка регистрации журнальных файлов. Синтаксис:

DELIMITER //
CREATE EVENT eventName
ON SCHEDULE EVERY 1 WEEK
STARTS 'Some Date to start'
ENDS 'End date If any' 

DO
BEGIN
   // Your query will be here
END//
DELIMITER ;

Для получения дополнительной информации посетите официальный сайт: http://dev.mysql.com/doc/refman/5.1/en/create-event.html

подробный блог: http://goo.gl/6Hzjvg

Ответ 4

Я иду с расписанием событий mysql

потому что нам не нужно указывать для него один дополнительный файл, наша цель может быть выполнена путем написания одного запроса.

если требуется только работа с базой данных, тогда график событий mysql является хорошим выбором.

Ответ 5

Планировщик событий Mysql является преимуществом для общей среды хоста. С точки зрения времени, его также можно запланировать до второго. В отличие от cron, это с точностью до минуты, но вы можете обойти это ограничение.

Ответ 6

Я сам сейчас работаю с СОБЫТИЯМИ и обдумываю то же самое.

В дополнение к ответам выше:

• Используйте СОБЫТИЯ, если задача полностью ориентирована на данные или дополняет функциональность, уже встроенную в базу данных. Возможно, у вас уже есть триггеры, которые очищают данные, регистрируют определенные события, агрегируют определенные данные и т.д. Если запланированное задание, которое вы хотите выполнить, является частью существующего проекта, более сплоченно запускать задание из СОБЫТИЯ. В конце концов, СОБЫТИЯ - это временные триггеры.

• Если вы запускаете скрипт из оболочки, вам нужно имя пользователя/пароль, сохраненные в скрипте оболочки или в файле по умолчанию. Для выполнения СОБЫТИЙ вам не нужны имя пользователя/пароль после создания СОБЫТИЯ.

• IMCO вы должны написать логику в хранимой процедуре; затем вызовите процедуру из СОБЫТИЯ или из сценария оболочки, что вам больше подходит. Вы могли бы даже создать какое-то место в вашем пользовательском интерфейсе, которое позволяет пользователям вызывать процедуру вручную.

Ответ 7

Это был давний вопрос, но я предполагаю, что одним из преимуществ использования событий mysql является его непосредственное встраивание в dbms, поэтому ему не нужно создавать/поддерживать соединение, если, например, вы используете php в качестве основного языка, вы могли бы также рассмотреть это При этом вы исключаете необходимость проверки при создании соединения с БД, прежде чем сможете выполнить оператор, а также вы можете создать событие, используя роль, которая может выполнять сценарии обслуживания и назначать роль пользователя приложению, которое этого не делает. обеспечит вам уверенность в том, что вы знаете, что пользователи, имеющие только такую роль, могут получить к ним доступ, поэтому решение об использовании событий или задании cron зависит от системы, над которой вы работаете. Но следует обратить внимание еще на несколько триггеров одного и того же события, особенно если интервал представляет собой просто разницу, это всего лишь секунды, как каждые 5-10 секунд и т.д.