安全删除前须查系统表：触发器查information_schema.triggers，存储过程查information_schema.routines并用routine_type过滤；跨库需替换database()为库名；注意权限、命名规范及依赖检查。
直接删掉就行，但必须先确认存在、权限够、没被依赖——否则不是报错就是误伤业务逻辑。
怎么安全查出所有触发器和存储过程？
别靠记忆或猜名字，系统表才是唯一可信来源。触发器藏在 information_schema.triggers，存储过程在 information_schema.routines（注意：routines 里同时包含 PROCEDURE 和 FUNCTION，需用 routine_type 过滤）。
- 查当前库所有触发器：
SELECT trigger_name, event_object_table, action_timing FROM information_schema.triggers WHERE trigger_schema = DATABASE(); - 查所有存储过程（不含函数）：
SELECT routine_name, created, last_altered FROM information_schema.routines WHERE routine_schema = DATABASE() AND routine_type = 'PROCEDURE'; - 跨库查？把
DATABASE()换成具体库名，比如'my_app'
重点看 event_object_table 和 created 字段——前者能帮你判断触发器是否还关联着活跃表，后者能看出是不是测试期随手建的“僵尸过程”。
删除前必须绕开的三个权限与命名陷阱
DROP TRIGGER 和 DROP PROCEDURE 都要求 DROP 权限，且默认只对当前库生效。常见翻车点：
- 执行
DROP PROCEDURE clean_old_logs报错Procedure does not exist？先确认当前USE的库是否正确，或改用DROP PROCEDURE mydb.clean_old_logs - 提示
Access denied？说明用户缺权限。高权限账号执行：GRANT DROP ON PROCEDURE mydb.* TO 'dev'@'%'; FLUSH PRIVILEGES; - 触发器名带横线或大小写？MySQL 默认不区分大小写，但若建时用了反引号（如
`log-updater`），删时也得带：DROP TRIGGER IF EXISTS `log-updater`;
永远加 IF EXISTS——它不会让你少删一个，但能避免因名字拼错或已删导致的脚本中断。
批量清理残留对象的最小安全脚本
手动一条条删太慢，又不敢全删？用动态 SQL 构造安全批量命令，每次只生成、不执行，人工核对后再运行：
SELECT CONCAT('DROP TRIGGER IF EXISTS `', trigger_name, '`;')
FROM information_schema.triggers
WHERE trigger_schema = 'mydb'
AND trigger_name LIKE 'tmp_%' OR trigger_name LIKE 'test_%';
同理清存储过程：
SELECT CONCAT('DROP PROCEDURE IF EXISTS `', routine_name, '`;')
FROM information_schema.routines
WHERE routine_schema = 'mydb'
AND routine_type = 'PROCEDURE'
AND created <p>输出结果复制粘贴执行即可。注意：这类脚本不能直接 <code>EXECUTE</code>，因为 <code>DROP</code> 不支持变量名；也别用 <code>TRUNCATE</code> 或 <code>DELETE</code> 系统表——那是自毁行为。</p><h3>删完还要盯住的两个隐形依赖</h3><p>触发器和存储过程本身删了，但它们可能还在影响别的东西：</p>
- 应用代码里硬编码调用了某个存储过程？删完后应用报
PROCEDURE does not exist就是这个原因。建议清理前 grep 代码库里的CALL和TRIGGER - 某些监控脚本或定时任务（如
EVENT）里写了CALL cleanup_proc()？检查SHOW EVENTS;和 crontab / 定时任务配置
真正麻烦的从来不是删的动作，而是删完才发现某处日志突然不写了、某张表的更新不再记操作时间戳——那八成是某个被遗忘的触发器默默工作了两年。
