Использование событий MySQL на практике

Спасибо

хоть и активно использую MySQL, но про события не знал (видать еще не возникало ситуаций когда пригодилось бы), автору спасибо за статью, добавил в закладки

Кстати, очень хорошо подойдет для очистки базы от временных объектов вроде протухших сессий. Видимо, про events мало кто знает из разработчиков CMS — в каждой второй надо обязательно в крон повесить специальный скрипт.

Как я понимаю, это типа триггера но только по расписанию? Интересно, почему ввели новую сущность, а не расширили синтаксис триггеров для поддержки событий по дате?

Думаю все же лучше по старинке, производить необходимые действия по cron.
Спасибо, добавил в избраное

А как посмотреть список запущенных событий?

Скажите, а можно выполнять событие каждый день в 4:12, например (когда сервер не нагружен)? И чтобы время не «плыло». Из описанного синтаксиса непонятно.

Непонятно, почему разработчики это назвали событиями. Это ж задания (shedules).

В Firebird, например, EVENT — это событие, обрабатываемое на клиенте. Т.е. в триггере или процедуре создается событие (POST_EVENT), на клиенте срабатывает его обработчик, если клиент пожелал это событие принимать. Бывает полезно.

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

Хотелось бы внести пару ложек дегтя в бочку меда. Начну из далека.
Как только в MySQL появились события, я очень обрадовался, так как привык работать с job в оракл и этой функциональности очень не хватало, однако. На последней конференции по MySQL (которую уже устроил Oracle) мы пообщались с разработчиками на тему, а как вам events в MySQL. На что получили крайне забавный ответ, ал-я «Вася иди сюда, расскажи как много багов у тебя в этом долбанном шедулере». Т.е. по мнению разоработчиков качество кода, который им достался в наследство, оставляет желать лучшего.
Events мы все таки заюзали. Ибо фича полезное а я верю в лучшее.

Первые проблемы начались когда MySQL 5.5.11 начал слегда подвисать из-за того, что не мог создавать новый бинарный лог, если имелись незавершенные транзакции. Механизм у нас был заюзан очень активно. Особенностью MySQL event scheduler состоит в том, что если событие не завершилось, то оно все равно стартует ещё раз, по этому страховку, защиту от дурака, надо делать самим. Изначально мы её не сделали, и при подвисании события запускались в геометрической прогрессии, убивая БД полностью.
Эту проблему мы решили, ну сами дураки — сами и исправились. Сделали что-то типа:

-----------------------------------------------------------------------------
drop event if exists ev_refresh_decline_structures;
delimiter $$
create event ev_refresh_decline_structures
on schedule every 10 second
comment 'Refresh decline data'
do
main_sql:
begin
declare v_eexl_id int(10);
call event_start(v_eexl_id, 'paynet.ev_refresh_decline_structures');
if v_eexl_id is null then leave main_sql; end if;
call refresh_decline_structures(500);
call event_finish(v_eexl_id, 'paynet.ev_refresh_decline_structures');
end
$$
delimiter ;
-----------------------------------------------------------------------------
drop procedure if exists event_start;
delimiter $$
create procedure event_start(out o_eexl_id int(10), i_event_name varchar(64))
main_sql:
begin
declare v_lock_is_set int(1);

select get_lock(i_event_name, 0)
into v_lock_is_set;

if coalesce(v_lock_is_set, 0) = 0 then
leave main_sql;
end if;

insert into event_execution_logs(event_name, start_date)
values (i_event_name, now());

set o_eexl_id = last_insert_id();
commit;
end
$$
delimiter ;
-----------------------------------------------------------------------------
drop procedure if exists event_finish;
delimiter $$
create procedure event_finish(i_eexl_id int(10), i_event_name varchar(64))
main_sql:
begin
declare v_lock_is_set int(1);

update event_execution_logs
set end_date = now()
where eexl_id = i_eexl_id;

commit;

select release_lock(i_event_name)
into v_lock_is_set;
end
$$
delimiter ;
-----------------------------------------------------------------------------

Таким образом мы запретили одновременный запуск событий, а так же стали мониторить время выполнения оных и частоту запуска.
Через месяц мы били сильно удивлены. Мы заметили, что одно событие, которые должно запускаться раз в день в 2 часа ночи, запускается через раз, через 2!!! Особенностью шедулера так же является то, что если время события прошло то оно не будет запущено ещё раз. вроде все логично, но на практике, шедулер просто ПРОПУСКАЕТ события, иногда совершенно по непонытным причинам. В качестве workaround мы переписали код процедур выполняемых событий. таким образом чтобы запускать их можно было чаще а само время реальной отработки они контролировали сами.
В общем — будьте внимательны не натыкайтесь на наши грабли.

З.Ы. ввиду всех этих непонятностей, мы приняли решение написать свой шедулер для MySQL который будет лишен всех этих неостатков на Javaб чего и вам желаем