SQL触发器禁止直接读写BLOB等二进制字段，因IO流模型与事务上下文冲突；仅允许LENGTH等元数据操作，禁止LOAD_FILE、DBMS_LOB.READ等IO调用及CONVERT等隐式加载函数。
SQL触发器里直接读写 BLOB、VARBINARY(MAX) 或 LONG RAW 这类二进制字段，不是“不推荐”，而是数据库引擎明确禁止或必然失败——根本原因在于 IO 流模型与触发器执行上下文的硬性冲突。
触发器没有完整 IO 上下文，LOAD_FILE() 会直接报错
MySQL 的 LOAD_FILE() 是服务器端同步读文件函数，依赖 secure_file_priv 路径，且**只能在客户端会话上下文中执行**。触发器属于服务端原子事务的一部分，没有文件句柄、无权调用 OS 层 IO 接口。哪怕路径合法、权限到位，只要出现在 BEFORE INSERT 或 AFTER UPDATE 触发器里，MySQL 就会立刻拒绝解析，抛出：ERROR 1373 (HY000): Cannot load from table in stored function/trigger。
- 这个限制是语法层拦截，不涉及实际读取，连路径校验都不会走
- Oracle 的
DBMS_LOB.READ在BEFORE ROW触发器中同样失败，报ORA-22997 - PostgreSQL 的
pg_read_binary_file()同样不能在触发器中调用，会提示权限或上下文错误
SELECT 或 INSERT 二进制字段会引发锁表和超时
即使绕过 LOAD_FILE()，改用 SELECT blob_col INTO @var FROM ... 或在触发器里拼接 INSERT ... VALUES (... , ?) 带二进制参数，也极大概率导致事务卡死。因为：
- BLOB 数据通常不存于行内，而是以指针（locator）形式存在；触发器执行时若尝试解析或复制整个流，会触发隐式 LOB 定位器加载，阻塞行锁甚至页锁
- SQL Server 中，对含
VARBINARY(MAX)的行触发更新，若触发器内做SELECT，可能引发PAGEIOLATCH_SH等 I/O 等待，拖慢整个事务 - Oracle 复制场景下，LOB 列更新本身**不会触发触发器**，只有非 LOB 列变更才会——说明引擎已将 LOB 操作视为异步、延迟、不可观测的子过程
真正能安全做的，只有元数据操作
触发器唯一可信赖的操作，是对二进制字段做轻量级元数据判断，不触碰实际字节流：
- 检查长度：
LENGTH(blob_col) > 1024*1024，用于分流大文件到异步队列 - 记录哈希摘要（如果应用层已预计算）：
INSERT INTO audit_log (file_size, md5_hash, row_id) VALUES (LENGTH(?), ?, ?) - 设置状态标记：
SET NEW.status = 'pending_blob_upload'，把实际写入交给应用层补全 - 绝对不要在触发器里调用
CONVERT、CAST、SUBSTRING等可能强制加载 LOB 内容的函数
最常被忽略的一点：LOB 字段的“更新可见性”在不同数据库中不一致——SQL Server 只在非 LOB 列变更时才同步刷新 LOB 值，Oracle 复制中 LOB 更新甚至不进日志表。这意味着，你以为在触发器里“捕获到了变化”，其实什么都没捕获到。
