mysql触发器中调用udf的唯一合法写法是set @var = (select func_name(...))，直接写select或call会报错；必须确保插件路径、文件名、权限三者严格匹配，且网络型udf需设超时避免阻塞。
触发器里调用UDF的唯一合法写法
MySQL触发器中不能直接执行 SELECT http_post(...) 或 sys_exec(...) 这类语句，语法会报错。必须用 SET @var = (SELECT func_name(...)) 包裹，否则触发器创建失败或运行时报 ERROR 1222（结果集列数不匹配）。
常见错误写法：SELECT http_post('https://api.com', '{}'); → 报错CALL sys_exec('/bin/sh script.sh'); → 语法不支持
正确姿势：
SET @res = (SELECT http_post('https://api.com', JSON_OBJECT('id', NEW.id)));SET @ret = (SELECT sys_exec(CONCAT('/usr/bin/php /opt/hook.php ', NEW.id)));- 若函数返回 NULL，
@res也会是 NULL，需额外判断（但 UDF 本身通常不抛异常，只静默失败）
UDF注册后仍提示 function does not exist 的原因
不是函数没写对，而是路径、权限、命名三者中至少一个没对齐。MySQL 查找 UDF 时严格按 SONAME 字符串去 plugin_dir 下找文件，大小写、后缀、软链都算在内。
实操检查清单：
- 用
SHOW VARIABLES LIKE 'plugin_dir';确认目录，把编译好的mysql-udf-http.so放进去（不是.so.0.0.0，除非你显式软链） -
CREATE FUNCTION http_post RETURNS STRING SONAME 'mysql-udf-http.so';中的'mysql-udf-http.so'必须和磁盘文件名完全一致 - 文件属主必须是
mysql用户（chown mysql:mysql mysql-udf-http.so），且chmod 755 - MySQL 启动参数中不能设
secure_file_priv为非空值，否则INSTALL PLUGIN直接被拒
为什么调用UDF后INSERT变慢甚至卡死
因为 UDF 是同步阻塞执行的——MySQL 的 SQL 线程会等它返回才继续。哪怕只是发个 HTTP 请求，一旦目标服务响应超时（比如 30 秒），整个 INSERT 就卡住 30 秒，连接池迅速耗尽。
真实影响点：
- libcurl 默认无超时，必须在 UDF 源码里硬编码
CURLOPT_TIMEOUT_MS和CURLOPT_CONNECTTIMEOUT_MS（建议 ≤2000） - Redis UDF 同样危险：
redisConnect()若连不上，可能卡在 DNS 解析或 TCP SYN 重试上 - 所有网络 I/O 都发生在 mysqld 进程内，DBA 通常禁止上线这类插件（安全审计过不了）
- 从库上触发器也会执行，但你通常不希望备库去调 webhook 或发消息
更稳妥的替代方案：别让触发器碰网络
生产环境真正能长期跑通的做法，是让触发器只做一件事：写一行记录到队列表。剩下的交给外部进程。
典型结构：
- 建表：
CREATE TABLE outbox (id BIGINT AUTO_INCREMENT, table_name VARCHAR(64), row_id BIGINT, event_type VARCHAR(32), payload JSON, created_at TIMESTAMP DEFAULT NOW(), status TINYINT DEFAULT 0); - 触发器只写：
INSERT INTO outbox (table_name, row_id, event_type, payload) VALUES ('orders', NEW.id, 'created', JSON_OBJECT('id', NEW.id)); - 独立 Python/Node.js 进程轮询
outbox WHERE status = 0，调用 API 成功后UPDATE outbox SET status = 1 - 若必须低延迟，可用
REDIS_PUBLISH()（比 HTTP UDF 更成熟）代替轮询
这个模式下，触发器永远毫秒级返回，失败不影响主业务，重试、限流、日志都在应用层可控——而这是 UDF 永远做不到的。
