事件可以指定單次或以一定的間隔執(zhí)行 SQL 代碼。通常是將復雜的 SQL 語句使用存儲過程封裝好，然后周期性地調用存儲過程完成一定的任務。

事件無需建立服務端連接，而是通過一個獨立的事件調度器線程完成初始化。事件沒有輸入?yún)?shù)也沒有返回值，這是因為沒有連接也就不存在輸入和輸出了。啟用后，可以通過服務端日志查看執(zhí)行的指令，但是很難知道具體來自哪個事件。也可以查詢 INFORMATION_SCHEMA.EVENTS 表了解事件的狀態(tài)，例如最近一次執(zhí)行的時間。

與存儲過程類似，事件也需要考慮類似的問題。首先，事件增加了 MySQL 服務端額外的工作。雖然事件本身的負荷很小，但是事件調用的 SQL 語句可能對性能產(chǎn)生嚴重的影響。另外，事件也會有存儲過程那樣基于語句的復制帶來的那一類問題。事件比較好的應用是做諸如周期性的維護任務、重建緩存、數(shù)據(jù)統(tǒng)計、保存監(jiān)測和診斷的狀態(tài)值等任務。

下面的例子創(chuàng)建了一個事件，調用存儲過程每周對指定的數(shù)據(jù)庫運行數(shù)據(jù)表優(yōu)化：

CREATE EVENT optimize_somedb ON SCHEDULE EVERY 1 WEEK
DO 
CALL optimize_tables('somedb');

可以指定事件是否需要重復執(zhí)行。在某些情況下是沒問題的，但是有些情況則不行。以上面的例子為例，你也許是想在所有的副本上運行 OPTIMIZE TABLE 指令。但是，需要知道的是如果是全部副本都同時執(zhí)行這個操作的話，這會影響整個服務端性能（例如鎖表）。 而且，周期性事件可能會花很長事件才能完成，甚至有可能下一個事件還沒結束新的事件就又開始執(zhí)行了。MySQL 不會阻止這樣的情況，因此需要自己寫代碼實現(xiàn)相同任務的互斥。可以使用加鎖的方式達到這一目的：

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 可以保證即便是發(fā)生了異常也會釋放鎖。

雖然事件與連接無關，但是卻是與線程有關的。MySQL 服務端有一個主事件調度線程，可以通過在服務端配置中開啟：

SET GLOBAL event_handler := 1;

一旦啟用，這個線程會執(zhí)行指定調度的事件。可以通過查看服務端的錯誤日志來了解事件執(zhí)行的信息。

雖然事件調度器是單線程的，但是事件本身是可以并發(fā)執(zhí)行的。每次事件執(zhí)行的時候服務端會創(chuàng)建新的進程。在事件內(nèi)部，可以調用 CONNECTION_ID()獲取一個唯一的值（雖然實際沒有連接），實際返回的就是線程 id。進程和線程在事件執(zhí)行完后會銷毀。可以通過 SHOW PROCESSLIST 查看，在 Command 列中會顯示為 Connect。

雖然，進程創(chuàng)建了實際執(zhí)行事件的線程，但線程在事件完成后會銷毀，并不會放入緩存中，因此 Threads_created 這個狀態(tài)計數(shù)器并不會看到增加。

結語：事件與應用程序、或操作系統(tǒng)級的定時任務相比，由于沒有了 SQL 連接建立的過程，因此效率會更高，而且開銷不大。適用于需要周期性運行的 SQL 腳本任務，例如數(shù)據(jù)表優(yōu)化、生成統(tǒng)計報表數(shù)據(jù)等等。但是，需要注意，事件本身可能存在并發(fā)問題，這個可以通過加鎖解決。同時，如果事件需要重復執(zhí)行，最好是不要執(zhí)行過于復雜耗時的任務。

以上就是MySQL 使用事件（Events）完成計劃任務的詳細內(nèi)容，更多關于MySQL 用事件完成計劃任務的資料請關注腳本之家其它相關文章！