数据库表

本页整理应用市场相关的全部数据表。表结构以 DDL 为准，字段含义参考 wujies-app-market 的实体类；两者不一致处以 DDL 为准（已知的不一致在第 12 张表和 app_version 的索引上，各自小节里都写明了）。

建表脚本来源复制标题链接

全部 CREATE TABLE 都是 IF NOT EXISTS，重复执行安全，也不删任何已有表与数据。

三种数据，别混复制标题链接

合计 11 张表：目录 6、安装实例 4、迁移记录 1。

两点需要说清楚：

• 「按租户隔离」不等于「表里有 tenant_id 列」。 app_schema_history 有 tenant_id 且是 NOT NULL，但它不在 tenant.excludes 里，读写一律走 TenantHelper.ignore(...) —— 因为表结构在所有租户间共享，判据带上租户会让第二个租户 重复执行 DDL。而 app_version_menu 没有 tenant_id，属于平台级目录数据。
• 目录与安装实例混在同一套表里，但可以搬到中心服务：app-market.catalog.mode=remote 之后，安装侧只通过 IAppCatalogService 读目录。所以「目录表在本地库」只是 local 模式的 事实，不是架构约束，详见 应用市场 与 目录与版本形态。

所有表的公共约定：主键是 bigint 雪花 ID（MyBatis-Plus idType=ASSIGN_ID，应用侧赋值， 不是自增）；审计列与 RuoYi 规范一致（create_dept / create_by / create_time / update_by / update_time）；引擎 InnoDB，字符集 utf8mb4。

1. app_info —— 应用主表复制标题链接

用途：应用市场的目录主表，一行一个应用；平台方维护，全局一份。

其余展示类字段：summary、description（Markdown 详情）、icon、cover、screenshots （JSON 数组）、author、author_url、license、tags（逗号分隔）、remark。

PRIMARY KEY (`app_id`),
UNIQUE KEY `uk_app_code` (`app_code`),
KEY `idx_app_category` (`category_id`),
KEY `idx_app_status` (`status`)

生命周期：控制台（上架端）在应用创建/编辑时写入，status 由「上架/下架」动作切换。 安装侧只读，且必须走 IAppCatalogService，不许直接注入 AppInfoMapper。应用被删除时是 逻辑删除（del_flag='1'）。卸载应用不删这张表的行 —— 目录与安装实例是两件事。

2. app_version —— 应用版本表复制标题链接

用途：一个应用可以有多个版本，每个版本承载一份完整的 app.json（manifest_json）； 菜单模板、依赖、迁移脚本、配置表单都从这份清单解析。

另含 changelog（text）。

PRIMARY KEY (`version_id`),
UNIQUE KEY `uk_app_version` (`app_id`, `version`),
KEY `idx_version_status` (`status`)

生命周期：控制台在版本创建 / 上传安装包 / 发布时写入，status 由发布、弃用、下架动作切换。 安装与升级按 version_id 读取 package_url 拉包（远程目录模式下同样经 IAppCatalogService）。

3. app_category —— 应用分类表复制标题链接

用途：应用市场的分类树，纯展示与筛选用。

PRIMARY KEY (`category_id`),
KEY `idx_category_parent` (`parent_id`)

生命周期：控制台维护。用户版（edition=client）里分类的读接口保留、写接口被 MarketEditionGuardFilter 挡成 403 —— 市场页要用它做筛选。卸载应用不影响这张表。

4. app_plan —— 应用套餐表复制标题链接

用途：应用套餐与价格定义（M3 计费）。当前未见实现：DDL 里有这张表，但 wujies-app-market 的 domain/ 下没有对应实体类，mapper/ 下没有对应 Mapper， 也没有任何服务或控制器引用它。字段含义按 DDL 注释整理，未在代码中验证。

PRIMARY KEY (`plan_id`),
KEY `idx_plan_app` (`app_id`)

生命周期：未找到写入方。它被列在 tenant.excludes 里，属于平台级目录数据 （同一份目录服务上还是本地）。建表脚本的回滚段会把这张表一起 DROP。

5. app_dependency —— 应用依赖表复制标题链接

用途：应用之间的依赖声明（哪个应用需要哪个应用、版本范围是多少）。 当前未见实现：没有实体类、没有 Mapper、没有引用点；字段含义按 DDL 注释整理。

PRIMARY KEY (`id`),
UNIQUE KEY `uk_app_dep` (`app_id`, `dep_app_code`)

生命周期：未找到写入方。与 app_info 同类，列在 tenant.excludes 里，属平台级数据。 注意这张表没有审计列，也不继承任何实体基类 —— 与 app_version_menu 一样是纯关联表。

6. app_version_menu —— 应用版本菜单关联表复制标题链接

用途：菜单归属的权威记录。应用上架时把清单里的菜单幂等 upsert 进 sys_menu， 并在此登记 menu_key → menu_id 的映射；租户开通应用时，就是把这些 menu_id 并入该租户的 套餐 / 角色授权。详细推导见下文第 12 节。

PRIMARY KEY (`id`),
UNIQUE KEY `uk_version_menu` (`version_id`, `menu_id`),
UNIQUE KEY `uk_version_menu_key` (`version_id`, `menu_key`),
KEY `idx_version_menu_menu` (`menu_id`)

生命周期：由菜单同步（AppMenuSyncServiceImpl）在安装 / 升级 / 手动「重新同步菜单」时写入， 按 menu_key 幂等 upsert，租户已分配的权限不能失效。读取方是菜单归属反查 （AppMenuOwnershipProvider：app_install → app_info → app_version → 本表）与「彻底删除」。

「彻底删除」时这张表的映射按三条线索并行清理（menu_id ∈ 本次删掉的菜单 ∪ menu_key ∈ 清单声明的键 ∪ version_id ∈ 该应用已知版本），少一条就会留下「死映射」—— 下次安装复用指向已删除菜单的 ID，表现为「安装成功、状态 enabled，但一个菜单都没有」。

7. app_install —— 租户应用安装实例表复制标题链接

用途：多租户核心表。一个租户对某个应用至多一条记录，状态迁移由状态机约束。

PRIMARY KEY (`install_id`),
UNIQUE KEY `uk_tenant_app` (`tenant_id`, `app_id`, `del_flag`),
KEY `idx_install_tenant_status` (`tenant_id`, `status`)

uk_tenant_app 把 del_flag 也算进了唯一键：这是「同一租户同一应用的历史安装记录」与 app_version 不同的处理方式 —— 一个应用在同一租户下卸载过再装，靠的是复用同一条记录 （状态回到 enabled），而不是插新行。

生命周期：AppInstallServiceImpl 编排安装 / 升级 / 启用 / 停用 / 卸载，每一步都写 status。「保留数据卸载」不删这一行，只把状态改成 uninstalled 并回收本租户授权； 「彻底删除」在这张表里做物理删除，且排在任务状态落库之后，否则终态无处可写。

app_install_task 与它的关系是「一次操作」对「一个实例」：任务记录在彻底删除时刻意保留 （审计线索），代价是历史行会显示「（应用已删除）」。

8. app_install_task —— 应用安装任务表复制标题链接

用途：安装 / 升级 / 卸载是会产生副作用的操作，用户需要看到「现在到哪一步、花了多久、 失败原因是什么、完整日志」。接口立即返回 taskId，前端订阅进度。

PRIMARY KEY (`task_id`),
KEY `idx_task_install` (`install_id`),
KEY `idx_task_status` (`status`)

生命周期：任务开始时插入一行，AppTaskRecorder 不断追加 current_step / progress / log_text，结束时落 status 与 error_msg。它是排查问题的第一入口，比翻服务端日志快， 见任务中心。

彻底删除应用时刻意不删：这张表是「谁在什么时候卸载了什么」的审计线索，代价是安装记录删掉后 任务列表里查不到应用名（前端 appMissing 字段就是为此）。

9. app_subscription —— 应用订阅表复制标题链接

用途：租户对应用套餐的订阅记录（M3 计费）。当前未见实现：DDL 里有这张表， 但 wujies-app-market 下没有对应实体类与 Mapper，也没有引用点；字段含义按 DDL 注释整理。

PRIMARY KEY (`sub_id`),
KEY `idx_sub_tenant_app` (`tenant_id`, `app_id`),
KEY `idx_sub_status` (`status`)

生命周期：未找到写入方。它不在 tenant.excludes 里（带 tenant_id，交给多租户插件隔离）， 所以「按租户隔离」这一列的判断依据是配置而非列名。

10. app_audit_log —— 应用操作审计表复制标题链接

用途：应用操作的审计流水。当前未见实现：DDL 里有这张表，但没有对应实体类与 Mapper，也没有引用点；字段含义按 DDL 注释整理。当前事实上的操作记录在 app_install_task 的日志里。

PRIMARY KEY (`log_id`),
KEY `idx_audit_app_time` (`app_id`, `create_time`),
KEY `idx_audit_tenant` (`tenant_id`)

生命周期：未找到写入方。同样不在 tenant.excludes 里。

11. app_schema_history —— 应用迁移执行历史表复制标题链接

用途：版本化迁移的账本。迁移引擎靠它判断「这个脚本跑过没有、内容有没有变」， 是最容易改错、也最值得看清楚的一张表 —— 详细解析见下文第 13 节。

PRIMARY KEY (`id`),
UNIQUE KEY `uk_schema_history` (`app_code`, `script`)

生命周期：AppMigrationService 在每个脚本执行后写一行（读写都走 TenantHelper.ignore(...)）。 checksum 是按脚本比对的，所以幂等的最小单位是「脚本」而不是「版本」。 「彻底删除」时必须删掉该应用的全部账本行，否则重装时建表脚本会被「已执行过」跳过，表再也建不回来。

12. app_version_menu 与菜单归属复制标题链接

这一节单独讲 app_version_menu，因为它是「哪些菜单属于这个应用」的唯一权威记录， 也是菜单保护与彻底删除的共同依据。

记录了什么复制标题链接

version_id  →  哪个应用版本
menu_id     →  sys_menu 里那一行
menu_key    →  应用清单里的稳定标识（幂等 upsert 依据）

三条线索各有用处：

• 上线（菜单同步）用 menu_key：同一个应用升级时清单里 menu_key 不变， 于是复用既有的 menu_id 而不是插新菜单 —— 这是「租户已分配的权限不能失效」的实现方式；
• 反查归属用 menu_id：AppMenuOwnershipProvider 由 app_install → app_info → app_version → 本表，得到「这个 menu_id 属于哪个应用」，菜单管理页据此打标签、禁用删除；
• 彻底删除用三者并行：见第 6 张表的生命周期说明。

为什么不用给 sys_menu 加 app_code复制标题链接

菜单同步时已经写下了这份映射，它就是权威记录。 再加一列会带来三个具体代价：

1. 要动框架的实体 / VO / Mapper XML / 菜单管理页面（sys_menu 是平台表，改它等于改框架）；
2. 会形成两份真相 —— sys_menu.app_code 与 app_version_menu 迟早不一致， 而两者的读者（菜单保护、彻底删除、工作台入口）对不一致的容忍度是零；
3. 归属必须是「版本 → 菜单」的关系，而不是「菜单 → 应用」：同一个应用的不同版本 可以有不同菜单树，按版本记录才能在升级时回答「这个菜单是这一版新加的，还是上一版就有的」。

13. app_schema_history 的唯一键复制标题链接

这一节单独讲账本表，因为它的错误形态不会在开发环境暴露，只会在生产安装时炸。

判据为什么是 (app_code, script)复制标题链接

曾经写错成什么样，后果是什么复制标题链接

表定义原本是：

UNIQUE KEY `uk_schema_history` (`tenant_id`, `app_code`, `version`)   -- 错误：少了 script、多了 version

而代码里的记账判据是 (app_code, script)。两者不一致的后果非常具体：

一个版本里只要有第二个迁移脚本，第二次记账就撞唯一键，整个安装 / 升级直接失败：

Duplicate entry '000000-exam-1.0.1' for key 'app_schema_history.uk_schema_history'

实测场景是 exam 1.0.1（migrations/01-create-exam-tables.sql + 02-create-exam-dictionaries.sql）升级报上面那句错。

修复脚本复制标题链接

script/sql/update/app_market_schema_history_fix.sql，幂等、可重复执行、不需要重启：

1. 先按 (app_code, script) 去重，同一组合只留 id 最小的那一行 （唯一键建不起来就白改了，所以先清干净）；
2. 用 information_schema.STATISTICS 判断后删掉旧键（MySQL 没有 DROP INDEX IF EXISTS）；
3. 建新键 UNIQUE KEY uk_schema_history (app_code, script)，已有 script 列则跳过；
4. 打印 information_schema.STATISTICS 自检 —— 应当是正好两列。

平台建表脚本 app_market.sql 也已同步改正。回归测试 AppMigrationLedgerDdlTest 会在 DDL 与代码不一致时直接失败。

记账之后的连带动作复制标题链接

• 脚本内容不能改：同一个 script 再出现时比对 checksum，不一致直接报错拒绝执行 —— 否则同名脚本会跑出两种结果，无法回溯。要变更请新增脚本。 ⚠️ 工作区是 CRLF、Linux 上是 LF，语义相同摘要不同，所以 checksumMatches 同时认两种摘要 （记账统一存 LF 归一化摘要），真正的改动照旧拒绝。
• 改过已执行脚本的做法是「先修账本、再升级」：把 5 个应用的 01-*-tables.sql 里的示例数据 拆到新脚本后，存量部署必须先跑 script/sql/update/app_market_app_seed_split_repair.sql 删掉那几行账本记录， 否则升级会被「脚本已被修改」挡住。
• 迁移只做 up，不回滚：MySQL 的 DDL 隐式提交，没法整体回滚；重试时已成功的会跳过。
• 脚本里补的字典 / 站点配置要失效缓存：执行后 AppMigrationService 自动清 SYS_DICT / SYS_DICT_TYPE / SYS_CONFIG，否则接口继续返回迁移前的标签。

14. 卸载时会删哪些表复制标题链接

「彻底删除」（purge=true）会 DROP 应用自己的数据表，依据是应用包内 migrations/*.sql 里的 CREATE TABLE，而不是任何一份手工维护的表清单。

• AppMigrationService.declaredTables(appCode) 扫描落位目录 <pluginDir>/migrations/<appCode>/，按文件名排序逐个解析；
• parseDeclaredTables 是纯函数（有单测 AppPurgeTableParsingTest）：必须先剥注释 （-- / # 行注释与块注释，字符串字面量里的同形字符不动），否则脚本头部 「请用 CREATE TABLE IF NOT EXISTS」这类说明会被当成表名；
• 只认 CREATE TABLE：ALTER / INSERT / DROP 都不构成「拥有」某张表；
• 表名可以带反引号 / 双引号 / 方括号，也可以带库名前缀（db.tbl，取最后一段）。

这也解释了为什么建表语句必须放进应用包：包里没有脚本，平台就无从知道该删什么， 任务日志里会明确警告「该应用没有声明任何数据表」。

两道闸复制标题链接

闸一：别的租户还在用就不动全局的东西。 sys_menu、数据表、迁移记录、本机产物都是一个部署内全局共享的。只要 app_install 里还有状态非 uninstalled 的其它记录，就跳过菜单 / 表 / 迁移记录 / 产物的删除， 只在任务日志里说清楚。判据必须排除自己那条记录 —— 此时它的状态还没被改成 uninstalled （状态是任务成功后才落的），不排除的话每次卸载都会「发现还有一个租户在用」，功能直接失效。

闸二：平台表前缀受保护。 只删迁移脚本声明过的表，且名字命中以下前缀时一律跳过并告警：

sys_  app_  gen_  flow_  act_  qrtz_  snailjob_  undo_log

判据刻意是前缀而不是精确表名：平台表会持续增加（每个版本都可能加），精确名单一定会漏， 而漏的后果是删掉平台数据。防的场景很具体 —— 一个写错的脚本 （CREATE TABLE IF NOT EXISTS app_install）把平台表带下水。 删表前还会用 [A-Za-z0-9_$]+ 再校验一次表名，确保拼进 DDL 的字符串不可能带出注入。

一次彻底删除的完整清单复制标题链接

刻意不做：app_install_task 保留（审计线索）；对象存储里的图片等外部文件不删 （平台不知道它们属于谁，也不该替用户删文件）。

「保留数据卸载」（purge=false，默认）只做两件事：撤本租户授权 + unload（关子上下文、 类加载器、注销接口）。菜单行、数据表、账本、产物、安装记录全部保留。 两种模式的对比见应用生命周期。

未找到的信息复制标题链接

• app_plan / app_subscription / app_audit_log / app_dependency 的写入方： 四张表在 DDL 里齐全，但代码里没有实体类、没有 Mapper、没有引用点。
• app_install_task.tenant_id 与 app_audit_log.tenant_id 为何在 DDL 里可空、 而实体继承的 TenantEntity 语义上要求非空：未找到说明。
• 与订阅 / 计费相关的服务、接口、菜单：未找到。
• app_info.install_count 与 rating 的写入方（是否有统计任务）：未找到。
• 历史注释提到过、但当前代码中不存在的 app_route_index 表：表不存在， 它只是关于路由墓碑未来可选落库的一句设计说明。

相关阅读复制标题链接

• 数据模型 —— 目录 / 安装实例 / 迁移记录为什么必须分开
• 应用生命周期 —— 卸载的两种模式与两道闸
• 应用市场 —— 目录中心化与 IAppCatalogService 的边界
• 插件开发 —— migrations/*.sql 的写法与打包约定