数据库初始化与升级
Java 使用 Flyway 管理全部业务表及 Flowable 引擎表。首次准备空 MySQL 8 数据库，启动应用后自动执行迁移，不逐份手动导入 SQL。
初始化文件
迁移目录：art-admin/src/main/resources/db/migration/。
| 文件 | 内容 |
|---|---|
V1__init_schema.sql | 账号、权限、配置、内容、文件、通知、审计及任务底座表 |
V2__init_data.sql | 管理员、角色、字典、配置、维护任务、菜单与权限 |
V3__init_workflow.sql | 审批与 Flowable 表、通用分类、菜单及授权 |
V4__init_mall.sql | 商城业务表、必要配置、菜单及授权 |
默认交付初始化全部模块。版本表示全局顺序，具体新增版本以交付代码中的最大版本为准，不将某个文章里的版本号作为永久上限。
第一次登录前应知道
仅创建 admin / Admin@2026，无预设部门、岗位、邮箱或电话。登录后修改密码，再建立组织与实际角色。
不创建演示商品、仓库、库存、订单、商户凭据或审批实例。商城使用前建立基础资料和启用的默认仓库。内置人工支付不代表已接通第三方渠道。
确认初始化成功
检查应用日志、健康状态和 flyway_schema_history 中的成功迁移。默认初始文件为 V1–V4；后续发布有新增迁移时，以实际发布内容为准。再通过前端验证登录、菜单与关键模块。
系统表、商城表和 Flowable 表分别保留自己的字符排序语义，不统一替换：底座 utf8mb4_unicode_ci，商城 utf8mb4_0900_as_cs，引擎 utf8mb4_bin。
查看已执行的迁移
使用已有数据库客户端连接当前环境的 art_design 库，执行只读查询：
SELECT installed_rank, version, description, success
FROM flyway_schema_history
ORDER BY installed_rank;核对迁移与当前发布版本一致，success 为成功状态。如果应用启动前就连接失败，历史表可能还未创建，应先处理连接。重新启动已初始化的系统不会恢复管理员初始密码，也不会清空业务数据。
新增数据库变更
- 确认当前最大迁移号，创建更高版本的
V数字__业务描述.sql。 - 在隔离环境验证从空库安装和从已有发布版本升级。
- 同步更新 Entity、Mapper/XML、接口模型与必要权限数据。
- 升级前备份，部署后核对迁移日志及业务结果。
已发布脚本不编辑、删除或重新编号。重启只执行未完成的新迁移，不重新写入初始账号、授权或客户配置。构建使用 clean 去除旧 SQL 资源，但不能在运行实例所依赖的 JAR 上直接覆盖构建。
非空库与迁移失败
项目关闭 baseline-on-migrate 和 Flyway clean，不自动接管没有历史表的非空库。来自其他开发基线、Nest.js 或客户旧系统的数据库，需要单独设计迁移方案。
遇到校验和、版本或结构错误时保留日志与数据库，核对运行 JAR 中的 SQL 和已执行历史。不要删除历史表、修改校验和，或以 repair 掩盖不兼容结构。应用回退不等于数据库回滚。
首次安装前裁剪
审批与商城可以源码裁剪，不能只删 SQL，也没有运行时模块总开关。同步检查业务包、Mapper、依赖、装配、任务、权限、前端入口与测试。仅保留商城时版本可以为 V1、V2、V4，保持原版本号。
安装后不能通过删迁移卸载模块。详细裁剪范围见随包 db/migration/README.md，已有客户升级见 备份与升级。