触发器的创建与执行时机必须匹配业务逻辑
MySQL 触发器在
INSERT、
UPDATE或
DELETE语句执行前后自动运行，但不能指定“何时跳过”或“条件性触发”——它没有
IF NOT EXISTS语法，重复创建会报错
ERROR 1359 (HY000): Trigger already exists。 创建前先用
DROP TRIGGER IF EXISTS trigger_name;清理旧版本
BEFORE触发器可修改
NEW行值（如自动填充
created_at），
AFTER触发器不能改
NEW或
OLD，但能读取最终数据并做日志、同步等操作 触发器内禁止调用含不确定结果的函数，例如
NOW()、
RAND()、
UUID()在某些 MySQL 版本中会导致复制失败 避免在触发器里执行耗时操作（如远程 HTTP 请求、大表更新），它会阻塞原事务，拖慢主表写入
CREATE TRIGGER user_insert_log BEFORE INSERT ON users FOR EACH ROW BEGIN SET NEW.created_at = NOW(); SET NEW.status = IF(NEW.email LIKE '%@test.com', 'trial', 'active'); END;
存储过程的参数类型和调用方式直接影响可用性
MySQL 存储过程支持
IN、
OUT、
INOUT三类参数，但调用时必须严格匹配数量和顺序；漏传
IN参数会直接报错
ERROR 1318 (42000): Incorrect number of arguments for PROCEDURE。
IN是默认类型，值传入后不可被过程修改回传
OUT参数需用用户变量接收，例如
CALL get_user_count(@cnt); SELECT @cnt;过程内部若需提前退出，用
LEAVE label_name;配合
main_loop: BEGIN ... END main_loop;块结构，不能直接写
RETURN注意 SQL mode 影响：若启用了
STRICT_TRANS_TABLES，过程内插入非法数据会中断整个流程，而非静默截断
DELIMITER $$ CREATE PROCEDURE get_user_by_status(IN status_val VARCHAR(20), OUT total INT) BEGIN SELECT COUNT(*) INTO total FROM users WHERE status = status_val; END$$ DELIMITER ;
触发器与存储过程都不能访问临时表或使用动态 SQL
MySQL 限制了二者对运行时对象的操作能力：
CREATE TEMPORARY TABLE、
PREPARE/
EXECUTE在触发器和存储过程中均被禁止，否则报错
ERROR 1314 (0A000): CREATE TEMPORARY TABLE is not allowed in stored function or trigger或
ERROR 1315 (0A000): EXECUTE statement is not allowed in stored function or trigger。 想实现“根据输入表名查数据”，只能靠应用层拼接 SQL 后执行，或改用存储函数（但函数也不能含写操作） 日志记录建议写入普通表，而非试图用临时表缓存再批量落库 跨库操作要显式写全名，如
other_db.audit_log，否则默认在当前数据库下找表
权限和二进制日志会影响生产部署
触发器和存储过程的定义会被写入 binlog，如果开启了
binlog_format = STATEMENT，而过程里用了
NOW()这类非确定函数，从库重放时可能产生不一致；同时，创建者必须拥有
TRIGGER和
CREATE ROUTINE权限，且
super_priv在某些托管 MySQL（如阿里云 RDS）中默认关闭。 线上环境优先设
binlog_format = ROW，避免触发器导致主从数据偏差 用
SHOW TRIGGERS LIKE 'table_name';和
SHOW PROCEDURE STATUS WHERE Db = 'db_name';查看对象状态 导出含触发器/过程的库时，
mysqldump默认不包含它们，需加
--triggers --routines参数 触发器和存储过程不是“写完就能上线”的黑盒工具。它们嵌入在 SQL 执行链路中，一旦出错会卡住业务写请求，调试又缺乏堆栈信息。最常被忽略的是权限继承关系和 binlog 格式适配——开发本地跑通，上线就主从延迟甚至中断，往往就卡在这两点。
