show create trigger 报错 access denied 的主因是 select 权限粒度不匹配或 information_schema 访问被显式拒绝，而非缺少 trigger 权限；需授予目标库级 select 并确保 information_schema 可读。
SHOW CREATE TRIGGER 命令本身不依赖单独的“查看触发器定义”权限，但执行它需要两个前提：对触发器所在数据库有 SELECT 权限，且用户能访问 information_schema.TRIGGERS 表（该表元数据读取受全局 SELECT 权限或库级 SELECT 权限隐式覆盖）。
直接授予 SELECT 权限即可满足绝大多数场景，无需额外开 TRIGGER 或 CREATE ROUTINE——后者管的是创建/修改行为，不是“看”。
为什么 SHOW CREATE TRIGGER 会报错 Access denied？
常见错误不是缺触发器权限，而是权限粒度没对上。例如：
- 用户只有
SELECT权限在mydb.orders单表，但触发器定义存在mydb库里，而用户对整个mydb库没有SELECT权限 → 报错 - 用户被显式拒绝了
information_schema访问（极少见，但某些强管控环境会REVOKE SELECT ON information_schema.*）→ 查不到元数据，SHOW CREATE TRIGGER失败 - 触发器属于
otherdb，但用户只连了mydb且没权限 USEotherdb→ 执行SHOW CREATE TRIGGER t1时 MySQL 默认查当前库，找不到就报错，而非跨库查找
实操：授予查看任意触发器定义的最小权限组合
最稳妥的做法是授予库级 SELECT，并确保不阻断 information_schema 访问：
- 对目标数据库（如
appdb）授SELECT：GRANT SELECT ON appdb.* TO 'viewer'@'%' - 不要
REVOKE SELECT ON information_schema.*—— 默认允许，显式回收反而会断掉SHOW TRIGGERS和SHOW CREATE TRIGGER - 如果需跨多个库查看，逐个授权：
GRANT SELECT ON db1.* TO 'viewer'@'%'; GRANT SELECT ON db2.* TO 'viewer'@'%' - 不需要
TRIGGER权限，也不需要CREATE ROUTINE—— 它们和“查看定义”无关
验证是否真能看，别信 SHOW GRANTS
SHOW GRANTS FOR 'viewer'@'%' 只显示授权语句，不反映实际生效效果。必须实测：
- 用该用户登录：
mysql -u viewer -p -D appdb - 执行：
SHOW TRIGGERS;—— 看是否列出触发器 - 再执行：
SHOW CREATE TRIGGER trig_name;—— 看是否返回完整CREATE TRIGGER ...语句 - 若失败，检查错误信息：如果是
ERROR 1142 (42000): SELECT command denied，说明SELECT权限漏了；如果是ERROR 1356 (HY000): View 'information_schema.TRIGGERS' references invalid table(s) or column(s)，说明information_schema被显式限制了
生产环境容易忽略的点
权限变更后，旧连接不会自动更新权限缓存。尤其在容器化部署或长连接池场景下，FLUSH PRIVILEGES 不一定立即生效，更可靠的方式是让应用重连，或确认客户端已断开并重建连接。另外，MySQL 8.0+ 默认启用 caching_sha2_password 插件，如果用户认证方式不匹配，可能根本连不上——此时不是权限问题，而是连接层失败，别在权限上浪费时间排查。
