mysql触发器中禁止使用load data语句，因其在语法解析阶段即被硬编码拦截，错误代码error 1314与权限、配置无关；load data跳过sql执行流程，不触发任何触发器逻辑。
触发器里写 LOAD DATA 直接报 ERROR 1314
这不是配置没开、权限不够，也不是你拼错了 SQL，而是 MySQL 服务端在语法解析阶段就把它拦下来了。只要触发器定义里出现 LOAD DATA INFILE 或 LOAD DATA LOCAL INFILE，不管上下文如何，都会立刻抛出固定错误：ERROR 1314 (42000): LOAD DATA is not allowed in stored procedures, functions, triggers, or events。
这个限制从 MySQL 5.0 就存在，硬编码在 parser 层，和 local_infile、secure_file_priv、FILE 权限全无关系。哪怕你用 PREPARE + EXECUTE 动态构造语句，照样失败——它根本没机会走到执行环节。
常见误操作包括：
- 在触发器里调用一个含
LOAD DATA的存储过程，以为能绕过 —— 不行，报错一样 - 把
DEFINER设成 root 用户并授全权 —— 无效，语法层不认权限 - 改
my.cnf加local_infile=1—— 对触发器上下文零影响
LOAD DATA 本身就不走触发器路径
触发器依赖 INSERT/UPDATE/DELETE 的逐行执行上下文：要生成 NEW 和 OLD 行、要校验字段、要挂 BEFORE/AFTER 钩子。LOAD DATA 完全跳过 SQL 解析器和执行器，直接在 InnoDB 数据页批量写入，连单条 INSERT 都不生成，自然没有触发器可挂载的时机。
所以不是“触发器没生效”，而是“压根没被调用”。你查 information_schema.TRIGGERS 看到状态是 ENABLED，不代表它会在 LOAD DATA 场景下起作用。
验证是否踩坑，只需两步：
- 手动执行一条
INSERT INTO t VALUES ()，确认触发器行为正常 - 再用同样数据跑
LOAD DATA，发现预期逻辑（如created_at自动填充、日志表写入）全部静默缺失
想让导入数据也触发逻辑，必须换路径
如果业务强依赖触发器行为（比如审计日志、字段自动补全、跨表校验），就不能用 LOAD DATA，得把加载动作移出数据库内部逻辑：
- 改用批量
INSERT INTO t VALUES (),(),()：拆 CSV 为 1000 行/批，拼成单条多值插入，完整触发所有触发器，但性能下降 3–5 倍 - 应用层预处理：用 Python/Shell 读 CSV，在导入前补全
created_at、uuid等字段，再用LOAD DATA导入已完备的数据 - 异步解耦：通过 MySQL Event Scheduler 扫描标志表，查到新任务后调用
LOAD DATA INFILE（Event 不受ERROR 1314限制），或投递到 Kafka/RabbitMQ 由外部服务执行
注意：LOAD DATA 本身不参与事务，无论用哪种替代方案，它和主业务逻辑都不在一个事务里。主表写入失败回滚时，已导入的数据不会自动撤回——这个一致性缺口必须靠上层幂等设计兜底，比如先写待处理状态、再导入、最后更新完成状态。
