触发器中直接读写BLOB字段会卡死，因数据库不支持触发器内完整二进制流处理；应仅用触发器处理元数据，BLOB操作交由应用层或异步任务完成。
触发器里直接读写 BLOB 字段会卡死？别这么干
SQL 触发器中对 BLOB 字段做 SELECT 或 INSERT 操作，极大概率导致锁表、超时甚至事务中断。不是语法错，是绝大多数数据库（MySQL/PostgreSQL/Oracle）在触发器上下文里不支持完整二进制流处理——它压根没给你分配足够内存和 I/O 上下文。
- MySQL 的
BEFORE INSERT触发器里读取NEW.blob_col会报ERROR 1347 (HY000): 'xxx' is not BASE TABLE或静默截断 - PostgreSQL 的
BEFORE ROW触发器里访问NEW.blob_col返回的是 OID（旧版）或空值（v13+），不是真实二进制数据 - Oracle 的
BEFORE EACH ROW触发器能读:NEW.blob_col，但调用DBMS_LOB.READ会抛ORA-22997: LOB locators cannot be used in BEFORE row triggers
想记录 BLOB 元信息？用触发器 + 外部逻辑配合
真正可行的路径是：触发器只处理轻量元数据（大小、MD5、文件名、类型），把实际 BLOB 操作交给应用层或异步任务。比如用户上传头像后插入 users 表，触发器不该去压缩或缩略图生成，而该写入一条待处理记录到 pending_blob_tasks 表。
- 触发器内只允许：
NEW.blob_size := LENGTH(NEW.blob_data)（MySQL）、md5(NEW.blob_data::bytea)（PostgreSQL，仅小 blob） - 超过 1MB 的
BLOB，连LENGTH()都可能拖慢触发器执行——改用应用层计算并传入blob_size字段 - PostgreSQL 若用
BYTEA存小图，可用pg_column_size()替代length()，更准且略快
MySQL 中误用 LOAD_FILE() 在触发器里读本地文件？立刻停手
LOAD_FILE() 是服务器端函数，依赖 secure_file_priv 路径，且**不能在触发器、存储过程、函数中调用**——MySQL 直接拒绝解析，报错 ERROR 1373 (HY000): Cannot load from table in stored function/trigger。这不是权限问题，是语法限制。
- 哪怕你把图片放到了
/var/lib/mysql-files/，触发器里写LOAD_FILE('/var/lib/mysql-files/photo.jpg')也一定失败 - 替代方案只有两个：应用层读完再
INSERT；或用INSERT ... SELECT从外部临时表导入（需提前建好含BLOB列的临时表） - 如果真要“自动加载”，得靠外部脚本轮询某张控制表，而不是塞进触发器
PostgreSQL 的 BYTEA 和 Oracle 的 BLOB 在触发器里能“安全”操作的边界在哪？
所谓“安全”，指不崩溃、不锁死、不丢失数据。实际就是：只读不写、只查长度不查内容、只存 OID 不存实际流。
- PostgreSQL：可在
AFTER INSERT触发器里用pg_total_relation_size('my_table')查整表膨胀，但别碰NEW.blob_col的内容；如需校验，用encode(NEW.blob_col, 'md5')（仅适用于 ≤ 100KB） - Oracle：
BEFORE触发器完全禁止访问:NEW.blob_col内容；AFTER触发器可读，但必须用DBMS_LOB.SUBSTR且长度限制在 32767 字节以内，否则报ORA-06502 - 共性陷阱：所有数据库都禁止在触发器里调用外部命令（如
curl下载、convert缩图），这会让事务失去原子性和可回滚性
