17370845950

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% 的需求用原生函数或应用层处理更稳妥。