MySQL触发器中禁止使用返回结果集的SELECT语句，必须改用SELECT...INTO或INSERT日志表调试；函数调试可用SIGNAL抛出信息；触发器更新需DROP再CREATE；GET DIAGNOSTICS需配合异常处理器使用。
MySQL 触发器里不能用 SELECT 直接查结果？
MySQL 触发器中禁止使用返回结果集的 SELECT（比如 SELECT col FROM t），否则会报错 ERROR 1415 (0A000): Not allowed to return a result set from a function or trigger。这不是语法错误，而是 MySQL 的硬性限制。
调试时想“看看某条数据长啥样”，得换方式：
- 用
SELECT ... INTO把值存进用户变量或局部变量，再配合INSERT INTO log_table记录； - 写入日志表是最稳妥的调试路径，例如建一张
debug_log表，字段含ts DATETIME DEFAULT NOW()、msg TEXT，在触发器里执行INSERT INTO debug_log(msg) VALUES(CONCAT('old_id=', OLD.id, ', new_val=', NEW.val));； - 避免用
SELECT 1或SELECT 'debug'来“占位”——照样报错，必须无结果集。
如何让 MySQL 函数支持调试输出？
函数同样不许返回结果集，但可以利用 SIGNAL + 自定义错误消息临时“抛出”中间值，适合开发环境快速验证逻辑。
例如想检查参数是否为空：
IF p_input IS NULL THEN
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = CONCAT('DEBUG: p_input is NULL, called at ', NOW());
END IF;
调用时会中断并显示该消息，虽然不算优雅，但比反复查日志快。注意：SIGNAL 在生产环境要删掉，且不能用于存储过程以外的上下文（如视图或普通查询中不能用）。
- 函数内不能建临时表、不能用
INSERT写日志表（除非函数是READS SQL DATA或更宽松的特性，但仍有权限和二进制日志限制）； - 若函数被频繁调用（如在
SELECT中），SIGNAL会导致整个查询失败，慎用； - 更安全的做法：把核心逻辑拆到存储过程中，函数只做轻量计算，调试集中在过程里。
触发器修改后没生效？检查这三处
改完触发器代码，执行 CREATE OR REPLACE TRIGGER 不报错，但行为没变——大概率是没真正更新。
- MySQL 不支持
CREATE OR REPLACE TRIGGER（5.7 及以前会报错，8.0+ 仍不支持），必须先DROP TRIGGER IF EXISTS trigger_name，再CREATE TRIGGER； - 触发器名区分大小写（取决于系统变量
lower_case_table_names），重命名时漏改调用处或拼写不一致，会导致旧触发器还在运行； - 触发器绑定的是表结构快照，如果刚
ALTER TABLE增加了字段，但触发器里还引用旧字段名，不会报错，而是静默设为NULL—— 检查SHOW CREATE TRIGGER trigger_name确认字段是否存在。
为什么 GET DIAGNOSTICS 在触发器里总报错？
GET DIAGNOSTICS 需要前一条语句实际发生异常（如 INSERT 失败），而触发器里多数语句默认不抛错（比如 UPDATE 影响 0 行不算错误）。直接写 GET DIAGNOSTICS 会提示 ERROR 1318 (42000): Incorrect number of arguments for PROCEDURE。
真要用它捕获错误，得配合 DECLARE ... HANDLER：
DECLARE EXIT HANDLER FOR SQLEXCEPTION
BEGIN
GET DIAGNOSTICS CONDITION 1 @sqlstate = RETURNED_SQLSTATE, @errno = MYSQL_ERRNO, @text = MESSAGE_TEXT;
INSERT INTO debug_log(msg) VALUES(CONCAT('ERR:', @errno, ' ', @text));
END;
但注意：这个 handler 只捕获其后显式执行的语句，且无法捕获触发器自身语法错误（那些在加载阶段就拒绝了）。
复杂业务逻辑的触发器，建议控制在 20 行以内；超过就得考虑用应用层校验 + 存储过程封装，否则调试成本远高于收益。
