There is no log for scheduled events, unless they throw exceptions... in which case, you'll find an error written to the standard MySQL "hostname.err" error log. If there isn't an error, and they aren't still running, then they processed. Each event gets a new thread id in the processlist each time it fires and the thread is destroyed when the event is done.
One option you could use is creating a table for the purpose, and inserting log entries into that table from within the body of the event, or the procedure that the event calls.
Inside a running event, the CONNECTION_ID() function returns the id of the thread where the event is running, and you can use this function in queries that do your logging, if that's useful, such as inserting a log entry including that value when the event starts, and updating that log entry when the event is almost done.
Another option is a bit of a hack (some would say), but it also works -- you can generate a "warning" in the MySQL error log from within the event or procedure fired by the event by raising a SQL warning at the end of the event. Note that this only writes to the error log from within an event, and that's because there is no client connected.
SIGNAL SQLSTATE '01000' SET MESSAGE_TEXT = 'hey, this job ran';
On some of my systems where the MySQL error log is monitored by an external process "tailing" the error log file, I have scheduled events whose only purpose is to write a warning like this to the error file periodically, so that the external process never goes more than so many minutes without seeing "something" in the often-quiet error log, to keep it happy that it is properly seeing the correct log file growing.
You need the history of InnoDB to understand why. Here it goes:
WAR STORY
InnoDB and the query cache are in a constant state of war. InnoDB tends to be very heavy-handed when inspecting changes in the InnoDB Buffer Pool and then crosschecking the Query Cache for the same changes.
PEACE TREATY
Before MySQL 5.0, the query cache was disabled for InnoDB. Now, InnoDB interacts with it. To simplify matters, you can just disable the Query Cache by setting the query_cache_size to 0.
According to the MySQL Documentation on query_cache_time
If the server is started with query_cache_type set to 0, it does not acquire the query cache mutex at all, which means that the query cache cannot be enabled at runtime and there is reduced overhead in query execution.
TERMS OF SURRENDER
Setting query_cache_size to 0 is not a one-size-fits-all solution.
The reason for the war, in the first place, is overhead. InnoDB will always inspect changes. A bigger query cache will make InnoDB work that much harder. Disabling the query cache let's the InnoDB and Query Cache be happy. However, you (the Developer/DBA) might be a casualty of that war by means bad query performance, even with such a peace treaty in place.
Depending on the following
- Workload
- Frequency of Changes
- Frequency of reading the same data
you should set query_cache_size to whatever number you feel increases performance (This being tantamount to starting an underground movement).
EPILOGUE
In case you are wondering where I came up with this war story, please see my old post
Read it carefully because I learned this from Pages 209-215 of High Performance MySQL (2nd Edition)
I have recommended disabling the query cache to others before
NOTE : I realize the question was about the query_cache_type. It does have an effect on the query cache. Disabling the cache squashes InnoDB's dominance over it. Setting the query_cache_type manually simply forces the Developer/DBA to think carefully about the type of queries the query cache will encounter.
Best Answer
You didn't specify the interval
I have several examples of how to set up events
BTW make sure you enable the croning mechanism in my.cnf by adding this line
You don't have to reboot. Just run this
As the last step, you can create the event.