LOAD DATA绕过触发器是设计行为，因其跳过SQL解析与执行器，直接在InnoDB数据页写入，不生成单行INSERT，故无NEW行和触发器钩子；替代方案仅有批量INSERT、应用层预处理或事后补偿。
LOAD DATA 绕过触发器是设计行为，不是故障，也无法通过配置开启——它根本不会进入触发器执行路径。想靠它触发 BEFORE INSERT 或 AFTER INSERT，注定静默失败。
为什么 LOAD DATA 一定不触发触发器？
它跳过 SQL 解析器和执行器，直接在 InnoDB 数据页写入，不生成单行 INSERT，自然没有 NEW 行、没有钩子调度机会。哪怕你确认了以下所有条件，依然无效：
-
SELECT @@global.local_infile返回ON - 用户有
FILE权限且secure_file_priv允许路径 -
information_schema.TRIGGERS.STATUS是ENABLED - 触发器语法完全正确，且手动
INSERT能正常工作
这不是权限、配置或版本问题，是 MySQL 源码硬编码路径隔离的结果。
LOAD DATA 导入后字段没自动填充、审计日志缺失，怎么快速验证？
别急着改触发器，先确认是不是路径误用：
- 执行
SHOW PROCESSLIST，看导入时状态是否为Reading from net或Writing to net（LOAD DATA特征），而非Query - 手动执行一条
INSERT INTO t (col1) VALUES ('test')，观察created_at是否填充、日志表是否写入；若正常，但LOAD DATA无反应，基本锁定为路径差异 - 检查客户端工具：Navicat 的“导入向导”默认走
LOAD DATA，不是拼INSERT，容易被忽略
业务强依赖触发器逻辑时，有哪些真正能落地的替代方案？
没有“开启触发器开关”这种选项，只有三条可选路径，各带硬约束：
-
批量
INSERT替代：把文件拆成 500–1000 行/批，拼成INSERT INTO t VALUES (),(),()...。能完整触发所有逻辑，但导入速度下降 3–5 倍，且单条语句长度受max_allowed_packet限制 -
应用层预处理：用 Python/Shell 脚本读取原始文件，在导入前补全
created_at、uuid、校验字段等，再用LOAD DATA导入已完备数据。性能几乎无损，但需额外维护预处理逻辑 -
事后补偿 + 校验：接受
LOAD DATA静默跳过，导入后立即执行UPDATE t SET created_at = NOW() WHERE created_at IS NULL类语句补漏。必须配套做SELECT COUNT(*) FROM t WHERE created_at IS NULL校验，否则漏掉就真漏了
最容易被忽略的一点
触发器逻辑一旦被 LOAD DATA 绕过，不会报错、不发警告、不写 error log——它是彻底静默的。上线前必须明确：所有写入路径（INSERT、INSERT ... SELECT、REPLACE、LOAD DATA）是否都覆盖了你的业务一致性要求。尤其当 LOAD DATA 用于定时同步或灾备恢复时，这一环断掉，往往要等数小时后才发现数据不对。
