SHOW CREATE TRIGGER 返回的 Trigger 列是完整 CREATE 语句（含 DEFINER、时机、事件等），sql_mode 是创建时生效的 SQL 模式；直接复制执行易因 DEFINER 或 sql_mode 差异失败，且不支持模糊查询、大小写敏感、需先 USE 目标库。
SHOW CREATE TRIGGER 返回的字段含义不明确
执行 SHOW CREATE TRIGGER trigger_name 后，结果只有两列：Trigger 和 sql_mode。很多人误以为 Trigger 列是触发器名，其实它是**完整的 CREATE 语句文本**——也就是触发器的原始定义源码，含 DEFINER、BEFORE/AFTER、FOR EACH ROW 及全部逻辑。而 sql_mode 是该触发器创建时生效的 SQL 模式，不是当前会话模式。
容易踩的坑：
- 直接复制
Trigger字段内容到新环境执行可能失败，因为DEFINER用户（如`root`@`localhost`）在目标库可能不存在或无权限 - 没注意
sql_mode差异，导致迁移后触发器逻辑行为异常（比如STRICT_TRANS_TABLES关闭时插入超长字符串不报错，开启后会中断） - 用
\G格式查看时，字段名被隐藏，误以为输出不全
触发器名大小写敏感且必须精确匹配
SHOW CREATE TRIGGER 不支持模糊查询或通配符，触发器名区分大小写（取决于系统变量 lower_case_table_names 的设置，但触发器名本身按创建时字面量存储）。如果记不清名字，先用 SHOW TRIGGERS 或查 information_schema.TRIGGERS 确认。
常见错误现象：
-
ERROR 1360 (HY000): Trigger does not exist：名字拼错、大小写不符、或当前数据库非触发器所在库（该命令不接受database.trigger形式，必须先USE db_name） - 执行成功但返回空结果：实际是触发器存在但名称完全不匹配，MySQL 不报错也不提示，只返回空集
从 information_schema.TRIGGERS 查定义更灵活但需手动拼接
如果要批量导出或筛选定义，SELECT ACTION_STATEMENT FROM information_schema.TRIGGERS 是唯一选择。但要注意：ACTION_STATEMENT 字段只存触发器主体逻辑（即 BEGIN ... END 内部或单条语句），不含 CREATE TRIGGER 头部、DEFINER、EVENT、ON 表等元信息。
所以它适合快速看“干了什么”，不适合直接复用。若需完整重建语句，必须自己拼：
- 从
TRIGGER_NAME、ACTION_TIMING、EVENT_MANIPULATION、EVENT_OBJECT_TABLE等字段补全头部 -
ACTION_STATEMENT中的换行和引号可能被转义，直接拼接易语法错误 - 跨库查询时，
TRIGGER_SCHEMA必须显式指定，不能依赖当前库
权限不足时看不到 DEFINER 和完整语句
即使有 SELECT 权限访问 information_schema.TRIGGERS，若当前用户不是触发器 DEFINER 且没有 TRIGGER 权限，ACTION_STATEMENT 字段会显示为 NULL，SHOW CREATE TRIGGER 也会报 ERROR 1227 (42501): Access denied。
此时只能看到触发器存在（通过 SHOW TRIGGERS），但无法获知其逻辑。生产环境排查这类问题时，别只盯着语句写法，先确认账号权限是否覆盖 TRIGGER 和对应库表的 SELECT。
最常被忽略的一点：触发器定义中嵌套调用的存储过程或函数，其权限独立校验——即使 SHOW CREATE TRIGGER 成功返回，执行时仍可能因调用链上某环节权限缺失而静默失败。
