应禁用触发器而非优化它：当批量导入万级数据且触发器含日志插入、邮件发送等高开销操作时，执行频次成瓶颈；须确认无业务强依赖、避免事务内操作，并在异常后确保恢复启用。
禁用触发器再导入数据，比在触发器里加判断或改逻辑更直接有效——但必须确保禁用期间业务不依赖该触发器的副作用，且启用后无需补数据。
什么时候该禁用触发器而不是优化它
触发器在 INSERT、UPDATE 或 DELETE 每行执行一次，批量导入万级数据时可能放大为万次额外执行。若触发器本身含 INSERT INTO log_table、调用 sp_send_dbmail 或跨库查询，延迟会指数级上升。此时“优化触发器”意义不大，真正瓶颈是执行频次，不是单次逻辑。
- 导入前确认该触发器无业务强依赖：比如它只用于审计日志，且日志缺失可接受
- 检查是否有其他进程（如应用层监听、CDC、复制）依赖该触发器产生的副作用
- 避免在事务中禁用：若导入脚本自身在事务内，禁用/启用需在事务外执行，否则会报错
The context in which the current operation is executing does not allow for transaction control
SQL Server 中禁用与启用的具体命令
SQL Server 支持按触发器粒度控制，不用动表结构或权限。注意 DISABLE TRIGGER 对当前数据库生效，且对所有用户可见。
DISABLE TRIGGER [trg_after_insert_audit] ON [dbo].[orders];
导入完成后启用：
ENABLE TRIGGER [trg_after_insert_audit] ON [dbo].[orders];
- 禁用后仍可查
sys.triggers，字段is_disabled = 1表示已禁用 - 不能对
INSTEAD OF触发器使用DISABLE（SQL Server 不支持），只能临时删掉再重建 - 若触发器在视图上，需用
ON [schema].[view_name]，而非基表名
MySQL 和 PostgreSQL 怎么办
MySQL 没有原生触发器开关，常用替代方案是加运行时开关变量：
SET @skip_trigger_audit = 1;<br>INSERT INTO orders ...;
然后在触发器开头加判断：
IF @skip_trigger_audit = 1 THEN LEAVE proc_end; END IF;
PostgreSQL 没有 DISABLE TRIGGER 语法（12+ 版本才支持 ALTER TABLE ... DISABLE TRIGGER），旧版本得用 DROP TRIGGER + CREATE TRIGGER 组合，风险更高，务必在维护窗口操作。
- MySQL 的
@var是会话级，不影响其他连接，相对安全 - PostgreSQL 的
DISABLE TRIGGER默认禁用所有触发器，要精确控制请用DISABLE TRIGGER trigger_name - 无论哪种方案，导入脚本末尾必须校验触发器状态是否恢复，建议加
SELECT count(*) FROM pg_trigger WHERE tgname = 'xxx' AND tgenabled = 'O'（PG）或查sys.triggers（SQL Server）
真正容易被忽略的不是怎么禁用，而是禁用期间发生的异常：比如导入中途失败，脚本没走到启用语句，后续业务就静默丢失逻辑。务必把启用语句放在 TRY/CATCH 的 FINALLY 块（SQL Server），或用存储过程封装成原子操作。
