MySQL 的 `LOAD DATA INFILE` 不会触发触发器——这不是 Bug，也不是你配置没开对，而是它打一开始就设计成这样的。它压根就不走触发器能介入的执行路径，绕得干干净净。
## 为什么 LOAD DATA 完全绕过触发器
咱们先把它拆开说。`LOAD DATA INFILE` 的运作流程，是在存储引擎层直接写入数据页，跳过了 SQL 解析器和执行器的 DML 路径。而触发器呢？它依赖的是逐行 `INSERT` 的执行上下文——比如构造 `NEW` 行、校验权限、调用 BEFORE/AFTER 这些钩子。`LOAD DATA` 不生成任何单行 `INSERT` 语句，自然没有钩子可挂。
这意味着：
* 即便表上明明白白定义了 `BEFORE INSERT` 或 `AFTER INSERT` 触发器，`LOAD DATA` 导入时也完全静默，不报错、不警告、不触发
* 同样是批量操作，`INSERT ... SELECT` 会触发触发器，但 `LOAD DATA` 不会——二者底层路径完全不同
* 这个行为由 MySQL 源码硬编码控制，没有任何配置项能改变它（不存在类似 `sql_mode` 的开关让你一键开启）
这就好比什么呢？一个是乖乖排队走正门，每个步骤都经过检查；另一个直接翻跟斗进后院，绕过所有守卫。
## 别把“没触发”当成“被禁用”
很多团队遇到这个情况，第一反应是查 `ALTER TABLE ENABLE TRIGGER`。但这指令对 `LOAD DATA` 场景完全无效——触发器根本没被禁用，它只是根本没机会跑起来。
几个关键对比：
* SQL Server 的 `SqlBulkCopy` 默认 `FireTriggers = false`，但允许开发者显式设为 `true`；MySQL 呢？直接没这个开关
* 你查 `SHOW TRIGGERS LIKE 'xxx'` 看到 `Status` 是 `ENABLED`，这只能说明触发器本身是激活状态，不代表它会在 `LOAD DATA` 时生效
* 不少团队误判为“触发器失效”，结果花时间去 `ENABLE`、重编译、查权限，兜了一大圈才发现是工具选错了
最麻烦的地方在于——它不会给你任何反馈，不像索引冲突或外键约束那样有报错兜底。静默失效，这才是最危险的。
## 替代方案该怎么选
如果你的业务逻辑强依赖触发器——比如自动填充 `created_at`、写审计日志、校验字段值——那就不能用 `LOAD DATA`，必须换路径。
**方案一：改用批量 INSERT**
把文件拆成 1000 行一批，拼成 `INSERT INTO t VALUES (),(),()...` 这种形式。这样能触发所有触发器，但代价是速度下降 3–5 倍。在数据量大的场景下，这是个可接受的权衡。
**方案二：应用层预处理**
导入前用脚本把时间戳、UUID、状态字段这些该补的数据都补全，然后再用 `LOAD DATA` 导入已经完备的数据。这样既保持了导入速度，又不遗漏逻辑。
**方案三：接受不一致并事后补漏**
导入后专门跑 `UPDATE` 修正缺失字段，配合 `WHERE created_at IS NULL` 这类条件做事后校验。这种做法适合那些对数据完整性要求不那么严苛、或者事后能容忍短暂不一致的业务场景。
必须警惕的是——触发器逻辑一旦被 `LOAD DATA` 绕过，就等于整个一致性保障链条断了一环。它不像索引或外键那样有报错兜底，而是静默失效。上线前，必须明确每条数据写入路径是否都在触发器的覆盖范围之内。
