mysql不支持alter trigger，必须通过drop trigger+create trigger重建；触发器元数据固化于mysql.triggers表且不可更新，action_timing和trigger_name为主键组成部分；drop/create不可在事务中执行，需分独立会话操作并校验权限、binlog及连接池缓存影响。
DROP TRIGGER + CREATE TRIGGER 是 MySQL 唯一可行的“修改”路径，因为 MySQL 从 5.0 到 8.0 都没有实现 ALTER TRIGGER 语法。这不是设计疏漏，而是内核层面的硬性限制：触发器定义被固化为元数据对象，不支持就地更新。
触发器元数据不可变更
MySQL 把触发器当作只读结构体存入 mysql.triggers 系统表，字段包括 EVENT_MANIPULATION（INSERT/UPDATE/DELETE）、EVENT_OBJECT_TABLE、ACTION_TIMING（BEFORE/AFTER）、ACTION_STATEMENT（主体逻辑）等。这些字段在创建后即锁定——你不能用 UPDATE 去改 ACTION_STATEMENT，也不能 ALTER 表去扩展它。
- 尝试执行
ALTER TRIGGER ...会直接报错：ERROR 1064 (42000): You have an error in your SQL syntax - 即使只改触发器名字、或把
BEFORE UPDATE换成AFTER UPDATE，也必须重建——因为ACTION_TIMING和TRIGGER_NAME都是主键组成部分，不可单独更新
DROP 和 CREATE 必须拆开执行，不能包在事务里
触发器本身不参与事务控制，MySQL 明确禁止在事务中执行 DROP TRIGGER 或 CREATE TRIGGER：
- 如果你在
BEGIN ... COMMIT块里写这两条语句，会收到：ERROR 1305 (42000): FUNCTION does not exist（错误码可能偏移，但本质是语法拒绝） -
DROP TRIGGER一旦成功，原逻辑立即失效；中间不存在“原子切换”窗口 - 所以实操中必须确保：备份定义 → 独立会话执行 DROP → 独立会话执行 CREATE → 验证行为，三步不可合并
权限和 binlog 设置必须显式检查
重建过程不是简单删再建，两个环节权限不同、影响面也不同：
-
DROP TRIGGER需要当前用户有DROP权限（对库或表），不是ALL PRIVILEGES自带的 -
CREATE TRIGGER需要TRIGGER权限，且该权限是表级的，不会随GRANT ALL ON db.*自动下发 - 若会话中
sql_log_bin = OFF（比如某些备份工具或管理员临时关闭），新建的触发器不会写入 binlog，从库将缺失该对象，导致主从不一致
容易忽略的是连接池行为：pymysql、mysql-connector-python 等客户端在连接复用时，DROP 后其他连接仍缓存旧触发器定义，直到连接重建或服务端刷新（如 FLUSH TABLES）。这不是 bug，是 MySQL 协议层的设计事实。
最危险的盲区在于 OLD/NEW 可用性变化——比如把 BEFORE UPDATE 改成 AFTER UPDATE 后，你不能再在触发器里给 NEW.updated_at 赋值，否则报错 ERROR 1362 (HY000): Updating of NEW row is not allowed in after trigger。这种逻辑断裂不会在建表时报错，而是在第一次 UPDATE 时才暴露。
