MySQL觸發器的使用規則

觸發器可以在執行語句前或執行後觸發其他 SQL 程式碼執行。觸發器可以讀取觸發語句改變了哪些資料，但是沒有返回值。因此可以使用觸發器加強業務邏輯的約束而不需要在應用程式寫對應的程式碼。

從上述描述可以看到，觸發器可以簡化應用程式的邏輯並且可以提升效能，這是因為使用觸發器減少了應用程式和服務端的互動次數。同時，觸發器有助於完成自動更新歸一化和統計資料。例如，我們可以使用觸發器自動統計交易訂單總金額，訂單數及平均客單價。 然而，MySQL 的觸發器的應用場合也十分有限，如果你使用過其他資料庫產品的觸發器，不要以為 MySQL 也能實現相同的功能，例如：

• 每個資料表的單一事件只能有一個觸發器，也就是說對於 AFTER INSERT 這樣的事件來說，不能同時有超過1個的觸發器。
• MySQL 只支援行級別的觸發器，也就是隻能按 FOR EACH ROW 這種方式使用觸發而不是整個 SQL 語句，這對於大量資料的操作而言會比較低效。MySQL 的觸發器只能按下面的形式編寫：

CREATE TRIGGER 觸發器名 BEFORE|AFTER 觸發事件
ON 表名 FOR EACH ROW
BEGIN
    執行語句列表;
END

執行語句列表支援單條或多條語句，下面是一個多條語句的示例：

DELIMITER $$
CREATE TRIGGER user_create_log AFTER INSERT ON t_users FOR EACH ROW
BEGIN
DECLARE log_info VARCHAR(40)character set utf8;
DECLARE description VARCHAR(20) character set utf8;#後面發現中文字元編碼出現亂碼，這裡設定字符集
SET description = " is created";
SET log_info = CONCAT(NEW.user_name, description);     #函式CONCAT可以將字串連線
INSERT INTO logs(log) values(log_info);
END $$
 
DELIMITER ;

• 觸發器可能導致服務端實際執行的工作不可預測，一個簡單的語句可能導致服務端做大量不可見的工作。例如，如果一個觸發器更新了 一個相關的表，可能導致受影響的行數加倍。
• 觸發器難以除錯，並且一旦引入了觸發器，很難分析效能瓶頸。
• 觸發器會導致潛在的鎖等待和死鎖。如果觸發器失敗了，源查詢也會失敗。如果沒有意識到觸發器的存在，這類玩呢提很難發現。

大多數限制中，最大的限制是 FOR EACH ROW 的設計，這有時候導致觸發器沒法用於維護統計和快取表，這是因為這可能很慢。使用觸發器的主要理由是相比定時同步更新，觸發器可以一致保持資料的一致性。 觸發器也沒法保證原子性。例如，更新 MyISAM 資料表的觸發器在源 SQL 語句出錯後，無法回滾。而且，觸發器自身也可能都只錯誤。如果我們使用了 AFTER UPDATE 基於 MyISAM 資料表去更新另一個表。如果觸發器有個導致第二張表操作失敗的錯誤，那對於第一張表的操作不會回滾。

InnoDB 的觸發器相關的操作，包括源語句都在同一個事務中，因此是滿足原子性的。然而，如果使用InnoDB 的觸發器去與另一張表校驗資料一致性的時候，這個時候如果不小心的話可能導致不正確的結果。例如，假設需要使用觸發器模擬外來鍵，可以使用 BEFORE INSERT觸發器驗證另一張表是否存在對應的記錄，但是如果在觸發器讀取另一張表資料的時候不使用 SELECT FOR UPDATE的話，則由於併發性性問題可能導致錯誤的結果。 雖然觸發器有些缺陷，但是這並不意味著不能用。相反，觸發器本身也是有用的，尤其是對於約束，系統維護任務和保持統計資料保持最新。

也可以使用觸發器記錄資料行的變化。這樣即便是離線手動運算元據庫的記錄（如修復錯誤資料）也能夠被記錄下來。但是，需要注意的是對於往其他自增主鍵表插入資料時要小心，這對於複製性的語句表現會有問題，因為自增值對於兩個相同的副本值並不同。

觸發器在有限的場合能夠發揮其優勢，比如統計資料、資料表變更日誌等。但是也會有一些缺陷，比如大資料量的更新由於逐行觸發，會降低效率。還有就是，MyISAM 引擎無法保障原子性。因此，要根據應用場景是否要是有觸發器。