禁用触发器比删除更安全，因保留元数据、权限且可逆；SQL Server用DISABLE TRIGGER命令禁用单个或表级触发器，MySQL则需导出后删除或注释逻辑重建。
升级失败时，直接禁用触发器比删掉更安全
很多数据库升级失败（比如用友U8从v8.61升到v10.1报“日期不能小于源单据的日期”）本质不是触发器逻辑错，而是新旧版本表结构不兼容，导致触发器在升级过程中被意外调用并校验失败。这时候删掉触发器风险高、恢复难；临时禁用才是可控的第一步。
SQL Server 中如何安全禁用触发器
禁用比删除保留了元数据和权限，且可逆。关键命令是 DISABLE TRIGGER，不是 DROP：
- 禁用单个触发器：
DISABLE TRIGGER T_CheckDate1 ON RdRecord - 禁用整个表的所有触发器：
DISABLE TRIGGER ALL ON RdRecord - 禁用数据库内所有触发器（慎用）：
EXEC sp_msforeachtable 'DISABLE TRIGGER ALL ON ?'
注意：DISABLE 不影响触发器定义，也不需要备份内容；但升级完成后，必须人工确认是否要 ENABLE 回来——尤其当新版表结构已拆分（如RdRecord从1张变8张），原触发器大概率已失效，强行启用会报错。
MySQL 中没有 DISABLE TRIGGER，得换思路
MySQL 5.7+ 不支持禁用触发器语法，ALTER TABLE ... DISABLE TRIGGERS 不存在，也不能用注释绕过。实际可用的替代动作只有两个：
- 用
DROP TRIGGER IF EXISTS trigger_name删除，但必须提前用SHOW CREATE TRIGGER trigger_name导出定义，否则升级后无法还原 - 在迁移脚本开头加
SET SQL_LOG_BIN = 0（仅限主库），配合SET autocommit = 1，让触发器不执行——但这只对基于行复制的场景有效，且需确认 binlog 格式为 ROW
更稳妥的做法是：把触发器涉及的校验逻辑（如日期检查）临时注释掉，重建触发器。例如把 IF NEW.date 整行用 <code>-- 注释，再 DROP + CREATE。这样既跳过校验，又保留结构。
禁用后仍升级失败？重点查这三处
禁用触发器只是排除一个干扰项，不代表问题终结。如果升级还卡住，立刻检查：
- 错误日志里是否还有
ERROR 1442（MySQL）或Cannot execute trigger because table is already used（SQL Server）——说明还有其他触发器没禁全 - 升级脚本里是否包含
INSERT INTO ... SELECT类语句，而目标表上存在未禁用的AFTER INSERT触发器 - 触发器是否调用了存储过程或函数，而这些对象内部又隐式访问了被升级的表（这种嵌套调用不会被
DISABLE拦截）
真正麻烦的从来不是“怎么禁”，而是“禁哪些”和“禁完要不要开”。表结构大改后，旧触发器往往已无业务意义，留着反而埋雷。别默认想着恢复，先问一句：这个触发器在新版本里，还该存在吗？
