mysql的load data infile从不触发触发器是设计行为，因其直接在存储引擎层写入数据页，跳过sql解析与dml执行路径，不生成单行insert语句，故无法激活before/after钩子；该行为由源码硬编码控制，无配置可开启，替代方案需改用批量insert、应用层预处理或事后补漏。
MySQL 的 LOAD DATA INFILE 从不触发触发器，这不是 bug，也不是配置没开对，而是设计如此——它压根就不走触发器能介入的执行路径。
为什么 LOAD DATA 完全绕过触发器
MySQL 的 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 绕过，就等于整个一致性保障链条断了一环——它不像索引或外键那样有报错兜底，而是静默失效。上线前必须明确每种数据写入路径是否覆盖触发器预期。
