Navicat 不备份 BI 计算字段，因其仅存在于 BI 配置中，不在数据库结构内；需将计算逻辑下沉至数据库（如用 GENERATED ALWAYS AS 创建 STORED 列）才能被 Navicat 备份捕获并还原可用。
navicat 本身没有“虚拟列备份功能”——它不识别、不导出、不还原数据库层面的虚拟列（如 mysql 的 virtual 或 stored 列），更不会把计算字段（bi 层自定义字段）当作结构的一部分去备份。你看到的“计算字段”只存在于 navicat bi 的数据源定义里，和数据库表结构完全隔离。
为什么备份时永远看不到你的 BI 计算字段？
Navicat 备份（.psc 文件）只保存数据库对象：表、视图、存储过程、触发器、权限等。BI 中通过右键 return_date →「新建计算字段」创建的 rental_duration 是纯前端逻辑，存在本地配置或服务器 BI 项目中，不在数据库里，因此：
- 备份数据库时，该字段不会被写入
.psc - 还原数据库后，BI 图表会报错“字段 rental_duration 不存在”，因为数据源查询结果里压根没这列
- 即使你导出 BI 项目为
.nbi文件，那也只是 BI 配置包，不包含底层数据或表结构
想让计算逻辑“可备份”，必须下沉到数据库层
如果业务上真需要持久化计算结果（比如 rental_duration），得在 MySQL 表中显式建一列，并用 GENERATED ALWAYS AS 定义：
ALTER TABLE rental ADD COLUMN rental_duration INT GENERATED ALWAYS AS ( DATEDIFF(return_date, rental_date) ) STORED;
这样它才具备以下特性：
- 出现在
SHOW CREATE TABLE输出中，能被mysqldump或 Navicat 备份捕获 - 还原后自动可用，无需重新配置 BI
- 支持索引（
STORED类型），查询性能可控 - 注意：MySQL 5.7+ 才支持；
VIRTUAL列不占存储但无法索引，且 Navicat 查询设计器里可能显示为空值
BI 计算字段迁移时的实际操作路径
如果你坚持用 BI 层计算字段（比如依赖多个表 JOIN 后的聚合逻辑），那“备份”它的唯一方式是备份 BI 项目本身，并手动同步依赖项：
- 导出整个 BI 工作区：菜单 →「文件」→「导出项目」→ 选
.nbi格式（含所有数据源、图表、计算字段定义） - 但必须确保目标环境已存在同名数据源，且字段名、类型、大小写完全一致——
rental_date写成Rental_Date就会导致计算字段预览报错 - 若数据源基于 SQL 查询，记得把原始
SELECT语句也单独存为.sql文件——BI 项目里嵌的 SQL 可能被格式化或截断 - 计算字段中用了
AGGCOUNT()这类聚合函数？还原后首次刷新图表时，Navicat 会尝试执行带GROUP BY的子查询，若源表无主键或连接条件弱，可能超时或返回空结果
真正容易被忽略的点：BI 计算字段的表达式里若引用了当前用户变量（如 @user_role）、会话设置（如 @@time_zone）或临时表，那这个字段在另一台机器、另一个连接里根本跑不起来——它不是“可移植逻辑”，只是你本地的一次性快照。
