navicat 16 不支持多租户数据库批量升级自动化，因其缺乏租户识别、版本跟踪和条件化脚本分发能力；必须用 shell + mysql 命令行 + 版本表驱动实现，navicat 仅适用于写sql、验证单租户结果和导出结构比对。
navicat 16 本身不支持多租户数据库的批量升级自动化——它没有租户识别、版本状态跟踪或条件化脚本分发能力。真正在生产环境做这件事，必须绕开 navicat 的 ui 层，用外部脚本驱动命令行工具，并自行维护租户-版本映射关系。
为什么不能直接用 Navicat 的「自动运行」或「批处理作业」
Navicat 的「自动运行」只生成单个备份/同步脚本，不支持参数化（比如传入 tenant_id 或 schema_name）；「批处理作业」是静态文件列表，无法根据租户当前版本动态筛选应执行的迁移脚本。你建 100 个批处理作业，也得手动为每个租户单独配置、单独触发，根本谈不上“批量升级”。
- 所有 Navicat 生成的脚本都硬编码连接名，无法运行时注入变量
- 没有内置机制读取
schema_version表判断租户是否已执行某版本 - 遇到错误默认中断，不提供重试、跳过、记录失败租户等运维必需能力
真正可行的方案：shell + mysql 命令行 + 版本表驱动
核心逻辑是：查出所有待升级租户 → 对每个租户，找出高于其当前版本的迁移脚本 → 按序执行 → 更新该租户的 schema_version。Navicat 只用来辅助写 SQL 或临时调试，不参与执行流。
- 租户元数据存在一张
tenants表里，每行含id、schema_name、current_version - 迁移脚本按命名排序，如
001_init.sql、002_add_tenant_config.sql，放在migrations/目录 - 主脚本用
mysql -u root -p$PASS -D information_schema -sN -e "SELECT schema_name FROM tenants WHERE current_version 获取待升级租户列表 - 对每个租户，用
mysql -u root -p$PASS -D ${schema_name} -v ON_ERROR_STOP=1 -f migrations/002_add_tenant_config.sql执行 - 成功后立即更新该租户的
current_version，避免重复执行
Navicat 在这个流程里唯一靠谱的用途
它只适合三件事：写迁移 SQL 时语法高亮和表结构补全、手动验证单个租户升级结果、导出某个租户的当前结构用于比对。别指望它帮你管理租户差异或自动选脚本。
- 在「查询编辑器」里写
ALTER TABLE users ADD COLUMN tenant_id VARCHAR(32)比纯文本编辑器快，但写完得复制出去，不通过 Navicat 执行 - 右键租户库 →「转储 SQL 文件」可快速拿到 baseline 快照，用于 diff 工具比对升级前后差异
- 如果某租户升级失败，用 Navicat 连上去查
schema_version和 error log 表，比命令行翻日志直观
最常被忽略的一点：租户间可能共用基础表但隔离业务表，此时迁移脚本里不能写死 USE tenant_001，而要靠 -D ${schema_name} 参数动态指定库名——Navicat 的任何导出脚本都不带这个能力，必须手写 shell 封装。
