MySQL触发器内禁止执行LOAD DATA，报ERROR 1314，属语法硬限制，与权限、local_infile、secure_file_priv等配置无关；替代方案需移出触发器，如应用层调用、Event Scheduler或消息队列异步处理。
MySQL触发器里根本不能写 LOAD DATA，不是“不生效”，而是压根不让执行——语法层直接拦截，报错 ERROR 1314。
触发器中执行 LOAD DATA 必然报 ERROR 1314
这是 MySQL 自 5.0 起就存在的硬性语法限制，和权限、配置、路径、用户定义者（DEFINER）完全无关：
-
LOAD DATA INFILE和LOAD DATA LOCAL INFILE在触发器、存储过程、函数、事件中一律禁止 - 即使
SHOW GRANTS显示你有FILE权限，@@global.local_infile = ON，文件放在/var/lib/mysql-files/，照样失败 - 用
PREPARE/EXECUTE动态拼 SQL 也无效——解析阶段就拒绝，不进执行流程 - 错误信息固定为：
ERROR 1314 (42000): LOAD DATA is not allowed in stored procedures, functions, triggers, or events
为什么不能靠配置绕过？
因为 local_infile、secure-file-priv、FILE 权限这些，只控制「客户端直连时能否发起 LOAD DATA LOCAL INFILE」，而触发器运行在服务端存储程序上下文中，走的是另一套校验逻辑：
-
SET GLOBAL local_infile = ON对触发器无影响 -
secure-file-priv的路径限制也不参与触发器语句校验 - 试图在触发器里调用含
LOAD DATA的存储过程，同样会立即报ERROR 1314
替代方案必须脱离触发器上下文
真正能落地的解法，是把数据加载动作移出数据库内部逻辑：
- 应用层监听业务事件（如订单创建完成），再用带
allowLoadLocalInfile=true的 JDBC URL 或local_infile=1的 PyMySQL 连接发起独立LOAD DATA LOCAL INFILE - 用 MySQL Event Scheduler 定期扫描标志表（如
pending_imports），查到新记录后，在事件中调用LOAD DATA INFILE（Event 不受该限制） - 通过消息队列（Kafka/RabbitMQ）将导入任务异步投递，由外部服务读取并执行，彻底解耦
注意：Event 方案仍需确保 EVENT 权限，并留意 log_bin 和 binlog_format 配置，否则可能在复制环境中被跳过。
LOAD DATA 本身不参与事务原子性
哪怕你用 Event 或应用层调用成功了，也要意识到：LOAD DATA 是一个独立的、不可回滚的操作。如果它和主业务逻辑不在同一个事务里（事实上也不可能在），那么主表 INSERT 失败回滚时，已导入的数据不会自动撤回——这个一致性缺口必须由上层逻辑兜底，比如先写待处理状态、再导入、最后更新状态，配合幂等设计。
