根本原因是navicat默认按字母序生成ddl，不自动识别外键依赖链，导致子表先于父表创建而失败；须手动按依赖顺序（如customers→orders→order_items）逐批部署，并勾选“disable foreign key checks during synchronization”确保约束安全添加。
同步含外键依赖的表时，navicat 为什么报 “can't create table” 或 “unknown column in foreign key reference”
根本原因不是 navicat 不支持外键，而是它默认按字母顺序或表名顺序生成 ddl，不自动识别引用依赖链。比如 orders 表引用 customers，但 navicat 先建 orders 再建 customers，就会失败。
解决思路不是“等它自动排好”，而是主动干预执行顺序：
- 在结构同步的「对比结果」界面，右键任意表 → 选择
View Dependencies，它会列出该表直接依赖的所有父表（即被它外键引用的表） - 记下所有依赖关系图：比如
order_items → orders → customers，必须严格按customers → orders → order_items顺序部署 - 回到比对列表，取消勾选所有表；然后手动按依赖顺序逐个勾选 —— 先只勾
customers，点「部署」；成功后再勾orders，再部署；最后是order_items - 如果目标库已有部分表，且结构不一致，Navicat 可能试图用
ALTER TABLE ADD FOREIGN KEY，但源库定义里含ON DELETE CASCADE而目标库没启用FOREIGN_KEY_CHECKS，也会报错。此时需在部署前勾选Advanced Options → Disable foreign key checks during synchronization
视图/存储过程依赖其他视图时，同步失败提示 “View references invalid table/column” 怎么办
Navicat 结构同步对视图的依赖解析能力有限，尤其当 A 视图引用 B 视图，B 又引用 C 表，它不会自动推导三层依赖，而是按字面顺序创建，导致中间视图因底层对象不存在而创建失败。
实操中必须拆开处理：
- 先用结构同步把所有基础表（无依赖的表）和函数、存储过程同步完
- 再单独导出视图定义：
SHOW CREATE VIEW `view_name`，人工检查FROM和JOIN中涉及的对象是否已存在；若否，记下依赖路径 - 在 Navicat 的结构同步中，进入「Options」→ 勾掉
Create views，先跳过视图；等表和函数全部就位后，再开一次结构同步，只勾选视图并启用Ignore errors when creating views（允许创建失败，后续手动修复） - 更稳妥的做法：导出所有视图 SQL 到文件，用文本工具排序（按依赖深度），然后在 Query 标签页里手动分批执行，每批之间加
DELIMITER ;;和注释说明依赖依据
同步 PostgreSQL 分区表 + 外键时，Navicat 17 报 “relation does not exist” 的真实原因
PostgreSQL 分区表的子分区（如 sales_2024_q1）在系统目录中是独立 relkind = r 的表，但 Navicat 结构同步默认只识别主表（sales），不会自动发现并同步子分区，更不会重建继承关系或约束。外键若指向子分区，目标库没有对应子分区，自然报错。
这不是配置问题，是功能边界：
- Navicat 17 对 PostgreSQL 分区表的支持仅限于主表结构（
CREATE TABLE ... PARTITION BY），不包括CREATE TABLE ... PARTITION OF子句 - 若必须同步，得放弃图形界面：用
pg_dump --section=pre-data --table=sales导出主表定义，再用--section=data单独导出各子分区数据，最后手工补上ATTACH PARTITION语句 - 外键若定义在主表上（指向其他普通表），则结构同步可正常处理；但若外键定义在子分区上（极少见），Navicat 完全无法识别，必须手写迁移脚本
- 验证是否真为分区问题：在目标库执行
\d+ sales，看输出中是否有Partitioned table字样及子分区列表；若为空，说明分区结构根本没同步过去
同步 Oracle 物化视图或 SQL Server 计算列时，Navicat 显示“object type not supported” 怎么绕过
Navicat 结构同步的底层引擎对非标准对象类型有明确支持列表，Oracle 物化视图（MATERIALIZED VIEW）、SQL Server 计算列（AS (expr)）、MySQL 生成列（STORED GENERATED）虽在「支持对象」文档里被提及，但实际同步时若源库版本较新（如 Oracle 23c、SQL Server 2022），或定义含复杂表达式，仍会静默跳过或报类型不识别。
这时候不能靠重试或换选项，得降级处理：
- 物化视图：在 Oracle 源库运行
DBMS_METADATA.GET_DDL('MATERIALIZED_VIEW', 'MV_NAME')获取完整 DDL，粘贴到目标库 Query 标签页执行；注意替换BUILD IMMEDIATE为BUILD DEFERRED，避免首次刷新失败 - 计算列：Navicat 会把计算列当成普通字段同步，丢失
AS表达式。必须在同步完成后，进目标表「设计表」→「字段」标签页，手动编辑该字段，勾选Computed并填入原始表达式 - 所有这类对象同步后，务必检查
SELECT * FROM user_objects WHERE object_type LIKE '%VIEW%'（Oracle）或sys.computed_columns（SQL Server），确认对象状态为VALID或is_computed = 1
最易被忽略的是：Navicat 在结构同步日志里对跳过的对象只写一行 Skipped: MV_SALES_REPORT (materialized view)，不标红也不报错，很容易扫一眼就过——务必打开完整日志面板，Ctrl+F 搜 Skipped 和 Unsupported。
