sql server与mysql在多对多建模中存在关键差异：sql server要求外键引用列必须是primary key或unique约束，而mysql要求外键字段自身有索引；sql server自动为外键列创建非聚集索引，但不强制中间表字段为主键，且默认on delete no action，需手动配置级联规则。
Navicat 本身不区分数据库类型来“设计模型逻辑”，但**SQL Server 的多对多建模方式和 MySQL 有关键差异**：它不强制要求中间表字段必须是主键或带索引才能建外键（SQL Server 自动为外键列创建非聚集索引），但**仍必须满足类型一致、引擎/存储引擎无关（SQL Server 没有 MyISAM/InnoDB 概念）、且引用列必须是唯一约束（PRIMARY KEY 或 UNIQUE）**。你在 Navicat 中对 SQL Server 建模时，不能套用 MySQL 那套“先设联合主键再加外键”的惯性操作——容易导出失败或关系失效。
SQL Server 中间表字段必须引用 UNIQUE 或 PRIMARY KEY 列
MySQL 要求外键字段「有索引」，而 SQL Server 要求被引用列（即主表的 id）必须有唯一性约束（PRIMARY KEY 或 UNIQUE），否则 FOREIGN KEY 创建直接报错：Introducing FOREIGN KEY constraint may cause cycles or multiple cascade paths 或更常见的 There are no primary or candidate keys in the referenced table。
实操建议：
- 确认
student.id和course.id都已设为PRIMARY KEY（或至少一个是UNIQUE+NOT NULL） - 中间表
student_course的student_id和course_id字段类型必须与对应主表字段完全一致（包括INTvsINT IDENTITY、NOT NULL属性、是否带IDENTITY） - Navicat 模型里右键字段 → “设为主键”不是必须步骤；你完全可以只设
student_id + course_id为UNIQUE约束（更符合业务语义），再建外键
Navicat 对 SQL Server 不生成 ON DELETE CASCADE 默认行为
SQL Server 的外键默认 ON DELETE NO ACTION，而 Navicat 在模型中若未显式配置删除规则，正向工程生成的 DDL 可能漏掉 ON DELETE 子句，导致导出后实际行为是 NO ACTION（即删主表记录时若存在关联，直接报错阻断）。这和 MySQL 默认也不同。
容易踩的坑：
- 在 Navicat 模型中配置外键时，务必点开“更新/删除规则”下拉菜单，手动选
NO ACTION、CASCADE或SET NULL（注意：只有字段允许NULL才能选SET NULL） - 若依赖级联删除，
ON DELETE CASCADE在 SQL Server 中会隐式启用INSTEAD OF触发器机制，性能开销比 MySQL 更高，生产环境慎用 - Navicat 导出的建表语句中，
FOREIGN KEY定义若没写ON DELETE，SQL Server 就按默认NO ACTION处理——这不是 bug，是设计如此
SQL Server 中间表推荐用复合主键 + 唯一索引组合
虽然 SQL Server 允许仅靠 UNIQUE 约束支撑外键，但为查询效率和数据完整性，中间表仍应设 (student_id, course_id) 为 PRIMARY KEY（或 UNIQUE CLUSTERED INDEX），并额外为反向查询建单列索引（如 INDEX IX_course_id ON student_course(course_id)）。
Navicat 操作要点：
- 在
student_course表设计页，勾选student_id和course_id→ 右键 → “设为主键” → 自动生成PRIMARY KEY (student_id, course_id) - 单独为
course_id字段添加索引（右键字段 → “索引” → 新建索引 → 类型选NONCLUSTERED） - 不要依赖 Navicat “自动补索引”功能：SQL Server 不像 MySQL 那样在建外键时自动加索引，Navicat 对 SQL Server 的索引管理较弱，必须手动补
NOT NULL）和钥匙图标（是否主键/唯一），比反复试连线有用得多。
