MySQL UDF 必须用 C/C++ 编写并编译为动态库，通过 CREATE FUNCTION ... SONAME 注册；不可用 SQL 或存储过程替代，且需严格遵循类型约定、符号导出和初始化函数规范。
MySQL UDF 必须用 C/C++ 编写，不能用 SQL 或存储过程替代
MySQL 的 CREATE FUNCTION 语句只支持**外部编译的 C/C++ 函数**（即真正的 UDF），和存储函数（CREATE FUNCTION ... RETURNS ... BEGIN ... END）完全不同。后者是 SQL 层的存储例程，不叫 UDF，也不涉及动态库加载。如果你看到“用 SQL 写 UDF”，那一定是混淆了概念。
真实 UDF 流程是：写 C 源码 → 编译成 .so（Linux）或 .dll（Windows）→ 放到 MySQL 插件目录 → 用 CREATE FUNCTION ... SONAME 'xxx.so' 注册 → 才能在 SQL 中调用。
- MySQL 不校验 C 函数签名，但必须严格遵循
my_bool、long long、char *等类型约定，否则启动时可能崩溃或调用失败 -
mysql_config --plugindir是插件路径权威来源，别硬写/usr/lib/mysql/plugin—— 不同发行版路径不同 - UDF 函数名在 SQL 中全局可见，且不能与内置函数重名（如
my_abs可以，abs会报错）
注册 UDF 前必须确保函数符号可被动态链接器找到
编译时漏掉 -fPIC -shared 或导出符号不正确，会导致 ERROR 1126 (HY000): Can't open shared library 'xxx.so'。这不是权限问题，而是符号表缺失。
典型编译命令（Linux x86_64）：
gcc -fPIC -shared -I$(mysql_config --include) -o myudf.so myudf.c
- 必须用
mysql_config --include获取头文件路径，否则找不到mysql.h - C 源码中必须显式声明函数为
extern "C"（C++ 时），否则 C++ name mangling 会让符号名变成_Z8myaddintS_这类不可识别形式 - 用
nm -D myudf.so检查导出符号：应看到myadd（你的函数名）、myadd_init、myadd_deinit三个符号
UDF 初始化函数（xxx_init）返回非零值会导致 CREATE FUNCTION 失败
MySQL 在注册时会调用你的 xxx_init 函数做参数校验和资源预分配。如果它返回非零（比如 return 1;），CREATE FUNCTION 就直接报错 ERROR 1123 (HY000): Can't initialize function 'xxx'，不会继续执行。
常见错误写法：
my_bool myadd_init(UDF_INIT *initid, UDF_ARGS *args, char *message) {
if (args->arg_count != 2) {
strcpy(message, "myadd() requires exactly two arguments");
return 1; // ← 错！这里应 return 1 仅表示失败，但 message 必须以 \0 结尾且 ≤ 255 字节
}
initid->maybe_null = 0;
return 0; // ← 成功返回 0
}
-
message缓冲区大小固定为 256 字节，写超会内存越界 - 即使你不需要初始化逻辑，也必须定义
xxx_init和xxx_deinit，哪怕内容是空的return 0; -
args->args[i]是char **类型指针数组，实际值需通过args->args[i] != NULL ? *(args->args[i]) : NULL解引用
UDF 调用时无法访问表数据或执行 SQL，也不能加锁或阻塞
UDF 运行在 MySQL 服务线程上下文中，但它**不是存储过程，没有 SQL 执行能力**。你不能在 UDF 里调用 mysql_query()、打开新连接、读写表、或使用 pthread_mutex_lock()——这些操作会破坏 MySQL 内部状态，轻则报错，重则导致 mysqld crash。
它的唯一职责是：接收参数 → 计算 → 返回结果。所有输入必须由 SQL 语句显式传入（如 SELECT myudf(col1, col2) FROM t）。
- 若需查表逻辑，请改用存储函数 + 视图 + 应用层组合，而非强行塞进 UDF
- 全局变量或静态缓冲区在多线程下不安全，MySQL 可能并发调用同一 UDF；必须用线程局部存储（
__thread）或传参方式隔离状态 - 耗时过长的 UDF（如网络请求、大循环）会卡住整个查询线程，影响并发性能，这类场景应避免
真正用到 UDF 的场景其实很窄：高性能数学计算（如地理距离哈希）、特殊编码解码（base91、xxhash）、硬件加速接口（如 AES-NI 封装）。日常开发中，99% 的需求用原生函数或应用层处理更稳妥。
