Skip to main content

查看已安装的扩展

使用 INFORMATION_SCHEMA 视图查询已安装的扩展:
输出:
用法:
  • 可以在交互式会话和脚本中使用
  • 标准 SQL 接口,与 MySQL 工具兼容

检查扩展函数

验证扩展函数在安装后是否正常工作:

扩展目录

检查 VillageSQL 查找 .veb 文件的位置:
列出可用的扩展:

配置 veb_dir

要更改扩展目录的位置,请在 MySQL 配置文件中设置 veb_dir my.cnf / my.ini:
要求:
  • 路径必须是绝对路径(而不是相对路径)
  • 目录必须在服务器启动之前存在
  • MySQL 用户必须对该目录具有读取权限
  • 仅支持一个 veb_dir(不能有多个路径)
  • 更改后需要重新启动服务器才能生效
重启后验证:

故障排除

快速参考

找不到扩展

错误: Extension 'my_extension' not found 调试步骤:

安装后函数不可用

错误: FUNCTION my_func does not exist 调试步骤:

更新后扩展显示旧行为

症状: 在替换 .veb 文件并重新安装后,扩展仍然 运行旧代码。 原因: VillageSQL 会在第一次加载时将 .veb 文件扩展到 {datadir}/.veb_expansion_cache/。如果您 在不先运行 UNINSTALL EXTENSION 的情况下复制新的 .veb,服务器将继续 使用先前扩展的 .so,该 .so 已经加载到内存中。 解决方案: 始终遵循完整的 UNINSTALL → 替换 → INSTALL 流程:
然后,替换 veb_dir 中的 .veb 文件并重新安装:
如果扩展仍然显示旧行为,请在重新安装之前清除扩展缓存:

无法卸载扩展

错误: Cannot uninstall extension: types in use 解决方案:

库加载错误

错误: Cannot load library: undefined symbol 原因:
  • 缺少库依赖项
  • ABI 兼容性不匹配
  • MySQL 版本不正确
调试:

扩展名称验证错误

错误: Failed to load VEF extension 'extension_name' with log message Extension name mismatch 原因: manifest.json 中的扩展名称与 VEB 文件名不匹配。 调试步骤:
  1. 检查 VEB 文件名是否与清单文件匹配:
  2. 验证 manifest.json 中的 name 字段:
解决方案: 两个名称必须完全相同,使用下划线(请参阅扩展命名约定):
  • VEB 文件名:my_extension.veb
  • manifest.json:"name": "my_extension"
常见错误:
  • 在清单文件中使用连字符:"name": "my-extension"
  • VEB 文件名不匹配:my-extension.veb"name": "my_extension"
正确示例:

自定义类型比较错误

错误: Cannot compare types X and Y in = 原因: 比较的两侧都是自定义类型,但来自不同的类型或扩展。
解决方案: 确保比较的两侧使用相同的自定义类型。如果需要跨类型进行比较,请使用适当的类型转换函数显式转换一侧。
错误: Unable to implicitly cast a non-custom type during compare with a custom type in = 原因: 比较的一侧是自定义类型列,另一侧是无法自动转换为该类型的字面量或列。
解决方案: 使用类型的编码函数,字面字符串会自动转换为自定义类型。对于其他类型(整数、浮点数),请使用显式转换函数:

监控扩展使用情况

查询性能

使用 performance_schema 跟踪 VDF 执行时间:

自定义类型使用情况

跟踪哪些表使用自定义类型:

更新扩展

要将扩展更新到较新版本,请使用手动更新过程:
ALTER EXTENSION UPDATE 尚未支持,计划在未来的版本中提供。

手动更新过程

  1. 卸载当前版本:
  2. 替换 .veb 文件:
  3. 安装新版本:
  4. 验证更新:
数据安全: 如果表使用来自扩展的自定义类型,则必须在卸载之前删除或修改这些表。首先备份数据。
示例:

清理

移除孤立的扩展目录

VillageSQL 将 .veb 文件扩展到 {datadir}/.veb_expansion_cache/{name}/{sha256}/。旧版本会随着时间的推移而累积。
服务器重启会自动清理孤立的扩展目录。

复制

自定义类型需要 ROW 格式的 binlog。对于具有自定义类型列的表,不支持 STATEMENT 和 MIXED 模式。对自定义类型列执行的 INSERT、UPDATE、DELETE 和 ALTER TABLE 操作在 ROW 格式中都能正确复制。 INSTALL EXTENSION 不会复制——每个服务器管理自己的扩展。在复制开始之前,在每个副本上安装扩展,并使用与源相同的版本。服务器强制执行精确的版本匹配;版本不匹配会停止复制。 如果副本遇到它不识别的自定义类型,则复制将在 DDL 语句处停止——在 CREATE TABLEALTER TABLE 处,在任何依赖的 DML 应用之前。安装正确的扩展版本,然后恢复:
mysqldump 在输出中保留完全限定的自定义类型名称。只要在导入转储之前在目标服务器上安装了扩展,逻辑恢复就可以工作。
尚未测试与 Clone 插件、XtraBackup 和 InnoDB Cluster / Group Replication 的行为。在生产环境中依赖它之前,请测试您的恢复路径。

在 Docker 中使用扩展

在 Docker 中运行 VillageSQL 时,将本地目录挂载为 veb_dir,以便您可以从主机添加 .veb 文件,而无需重新构建容器。 Docker Compose 示例:
.veb 文件复制到主机上的 ./extensions/ 中,然后从 SQL 安装:
要验证正在运行的服务器正在使用的目录:

获取帮助

如果您遇到此处未涵盖的问题:
  1. 检查错误日志: 大多数扩展错误都带有详细信息记录在日志中。
  2. 查看扩展文档: 扩展特定的故障排除方法可能存在。
  3. 在 Discord 上提问: 加入 VillageSQL Discord
  4. 提交问题:GitHub Issues 上报告错误。

后续步骤

系统参考

查询系统表和视图

卸载扩展

安全地删除扩展

扩展架构

了解内部结构