MySQL的information_schema.TRIGGERS不包含真实依赖，因其仅存储显式元数据（如触发器名、绑定表、时机等），不解析ACTION_STATEMENT中的跨库表名、函数调用、子查询等隐式依赖。
MySQL 不提供直接查看触发器依赖关系的内置命令或视图，所有隐式依赖（如跨库表名、函数调用）必须人工解析 ACTION_STATEMENT 或 SHOW CREATE TRIGGER 输出。
为什么 information_schema.TRIGGERS 里查不到真实依赖？
MySQL 的 information_schema.TRIGGERS 表只记录显式元数据：触发器名、绑定表（EVENT_OBJECT_TABLE）、时机（ACTION_TIMING）、事件类型（EVENT_MANIPULATION）和截断后的主体语句（ACTION_STATEMENT）。它不解析 SQL 内容，因此以下依赖完全不会出现在字段中：
- INSERT INTO
audit.log_table中的audit库名 —— 这是硬依赖，删库即失效 - 调用自定义函数
validate_amount(NEW.amount)—— 函数是否存在、权限是否足够，全靠人工确认 - 引用其他表的别名或子查询，例如
(SELECT name FROM users WHERE id = NEW.user_id)——users表未在元数据中标记为依赖 - 使用了
sysdate()或user()等内置函数虽无风险，但若迁移到只读从库，user()可能返回代理账号而非真实操作者
怎么安全地提取依赖线索？
不能只看 ACTION_STATEMENT 字段，它默认被 MySQL 截断（上限约 64KB），末尾带 ... 就代表逻辑被砍了。必须用 SHOW CREATE TRIGGER 拿完整定义，再逐行扫描：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 执行
SHOW CREATE TRIGGER trigger_name;，注意Trigger列才是完整语句，sql_mode列只是会话设置，别混淆 - 重点搜索：
INSERT INTO/UPDATE/DELETE FROM后面的库名.表名组合（如log_db.audit_log） - 检查所有函数调用：
myfunc(...)、database()、schema()—— 它们可能动态拼接库名 - 留意字符串拼接：
CONCAT('log_', DATE_FORMAT(NOW(), '%Y%m'))这类写法意味着表名是运行时生成的，无法静态识别
跨库依赖容易漏掉的三个坑
很多 DBA 在做迁移或权限收紧时栽在这几处：
-
EVENT_OBJECT_TABLE字段只存触发器绑定的“主表”，不反映ACTION_STATEMENT里写的其他表 —— 即使你查的是emp表的触发器，它也可能往history.emp_changes写日志 - MySQL 5.7/8.0 默认关闭
log_bin_trust_function_creators，若触发器调用了非确定性函数（如UUID()），复制可能中断，但元数据里完全看不出 - 用
DEFINER = 'admin'@'localhost'创建的触发器，在目标环境没有该账号时会静默失败（尤其在从库上），而SHOW TRIGGERS不报错也不预警
真正可靠的依赖分析没法全自动。哪怕写脚本批量提取 SHOW CREATE TRIGGER 输出，也得人工过一遍正则匹配结果 —— 因为 SQL 语法太灵活，INSERT 关键字可能藏在注释里，也可能被变量拼接绕过。最省事的方式，是把触发器逻辑当普通业务代码审，而不是当成黑盒元数据来查。
