MySQL UDF使用表列整数参数触发Error Code:2013连接丢失问题

你的问题核心出在强制将args->args[3]转换为long long*并解引用的操作上。MySQL对不同类型的参数传递的内存结构不一样：

• 直接传入数值时，MySQL会把它包装成long long类型，这时候强制转换碰巧能工作；
• 但参数是unsigned tinyint(3)列时，该参数实际指向的是1字节的内存空间，你强行按8字节的long long去读取，会直接导致内存越界，触发MySQL服务器崩溃，表现就是“查询期间丢失连接”。

之前改列类型为varchar或用CAST转换没用，是因为你没从根本上修正参数读取的逻辑——只要还是用错误的强制类型转换读取参数，不管外部怎么转类型，内存访问越界的问题依然存在。

正确的参数读取方式 #

在UDF的init函数中，必须根据参数的实际类型来读取值，而不是盲目强制转换。可以通过args->type[N]判断参数类型，再对应读取：

// 替换原来的错误代码
long long def = 0;
if (args->null_value[3]) {
    // 处理参数为NULL的情况，比如设默认值或标记函数返回NULL
    def = 0; // 示例默认值，可根据需求调整
} else {
    switch(args->type[3]) {
        case INT_RESULT:
            // unsigned tinyint属于INT_RESULT类型，实际是1字节无符号整数
            def = *(unsigned char*)args->args[3];
            break;
        case LONG_LONG_RESULT:
            def = *(long long*)args->args[3];
            break;
        // 可根据需要添加其他类型的处理，比如DECIMAL_RESULT等
        default:
            // 处理不支持的类型，比如设置错误或返回默认值
            def = 0;
            break;
    }
}

验证步骤 #

1. 修改levenshtein.c中的参数读取逻辑为上述代码；
2. 重新编译UDF：

   gcc -fPIC -shared -o levenshtein.so levenshtein.c -I/path/to/mysql/include
   

3. 重新安装UDF（如果之前已创建，先执行DROP FUNCTION levenshtein2;再重新创建）；
4. 执行测试查询，确认不再出现Error Code:2013的问题。

额外提醒 #

MySQL UDF的参数类型判断和读取是关键，一定要严格按照官方定义的参数类型来处理，避免直接强制转换指针导致的内存错误。如果需要支持更多类型，要逐一对应处理，同时别忘了检查null_value标记，防止读取NULL参数引发的异常。

内容的提问来源于stack exchange，提问作者user21098501