事件（Events） 是在 MySQL 5.1後引入的，有點類似操作系統的計劃任務（cron），但是週期性任務是內置在 MySQL 服務端執行的。可以指定單次或以一定的間隔執行 SQL 代碼。通常是將複雜的 SQL 語句使用存儲過程封裝好，然後週期性地調用存儲過程完成一定的任務。
事件無需建立服務端連接，而是通過一個獨立的事件調度器線程完成初始化。事件沒有輸入參數也沒有返回值，這是因爲沒有連接也就不存在輸入和輸出了。啓用後，可以通過服務端日誌查看執行的指令，但是很難知道具體來自哪個事件。也可以查詢 INFORMATION_SCHEMA.EVENTS 表瞭解事件的狀態，例如最近一次執行的時間。
與存儲過程類似（參考：MySQL 高級特性（六）：存儲過程的優缺點分析），事件也需要考慮類似的問題。首先，事件增加了 MySQL 服務端額外的工作。雖然事件本身的負荷很小，但是事件調用的 SQL 語句可能對性能產生嚴重的影響。另外，事件也會有存儲過程那樣基於語句的複製帶來的那一類問題。事件比較好的應用是做諸如週期性的維護任務、重建緩存、數據統計、保存監測和診斷的狀態值等任務。
下面的例子創建了一個事件，調用存儲過程每週對指定的數據庫運行數據表優化：
CREATE EVENT optimize_somedb ON SCHEDULE EVERY 1 WEEK
DO
CALL optimize_tables('somedb');
可以指定事件是否需要重複執行。在某些情況下是沒問題的，但是有些情況則不行。以上面的例子爲例，你也許是想在所有的副本上運行 OPTIMIZE TABLE 指令。但是，需要知道的是如果是全部副本都同時執行這個操作的話，這會影響整個服務端性能（例如鎖表）。
而且，週期性事件可能會花很長事件才能完成，甚至有可能下一個事件還沒結束新的事件就又開始執行了。MySQL 不會阻止這樣的情況，因此需要自己寫代碼實現相同任務的互斥。可以使用加鎖的方式達到這一目的：
CREATE EVENT optimize_somedb ON SCHEDULE EVERY 1 WEEK
DO
BEGIN
DECLARE CONTINUE HANDLER FOR SQLEXCEPTION
BEGIN END;
IF GET_LOCK('somedb', 0) THEN
DO CALL optimize_tables('some_db');
END IF;
DO RELEASE_LOCK('somedb');
END
看起來“多餘”的 continue handler 可以保證即便是發生了異常也會釋放鎖。
雖然事件與連接無關，但是卻是與線程有關的。MySQL 服務端有一個主事件調度線程，可以通過在服務端配置中開啓：
SET GLOBAL event_handler := 1;
一旦啓用，這個線程會執行指定調度的事件。可以通過查看服務端的錯誤日誌來了解事件執行的信息。
雖然事件調度器是單線程的，但是事件本身是可以併發執行的。每次事件執行的時候服務端會創建新的進程。在事件內部，可以調用 CONNECTION_ID()獲取一個唯一的值（雖然實際沒有連接），實際返回的就是線程 id。進程和線程在事件執行完後會銷燬。可以通過 SHOW PROCESSLIST 查看，在 Command 列中會顯示爲 Connect。
雖然，進程創建了實際執行事件的線程，但線程在事件完成後會銷燬，並不會放入緩存中，因此 Threads_created 這個狀態計數器並不會看到增加。
結語：事件與應用程序、或操作系統級的定時任務相比，由於沒有了 SQL 連接建立的過程，因此效率會更高，而且開銷不大。適用於需要週期性運行的 SQL 腳本任務，例如數據表優化、生成統計報表數據等等。但是，需要注意，事件本身可能存在併發問題，這個可以通過加鎖解決。同時，如果事件需要重複執行，最好是不要執行過於複雜耗時的任務。