SQL Server 的 ALTER TABLE 必须显式指定操作类型，不支持 MySQL 式隐式修改；改类型用 ALTER COLUMN，改列名须用 sp_rename，加约束用 ADD CONSTRAINT；Navicat 导出脚本含 USE 和 GO，需手动调整批处理；修改主键/外键列前须先删除依赖约束；datetime 转 datetime2 存在精度与兼容性风险，建议新增列迁移。
ALTER TABLE 语句必须显式指定操作类型
sql server 不支持像 mysql 那样在 alter table 后直接写字段定义来“隐式修改列”。比如 alter table t add col int 是添加，但想改类型或重命名，必须用 alter column 或 sp_rename —— navicat 的图形化界面点一下“修改列”，背后实际会拆成多条语句执行，而手动写 sql 时漏掉这层区分，就会报错 incorrect syntax near 'column' 或 cannot alter column because it is 'primary key'。
实操建议：
- 改数据类型（如
INT→BIGINT）：用ALTER TABLE ... ALTER COLUMN col_name BIGINT，但要求列不含NOT NULL约束或已有值全可隐式转换，否则先ALTER COLUMN ... NULL再更新再改回 - 改列名：不能用
ALTER COLUMN，必须调用系统存储过程sp_rename，语法是EXEC sp_rename 'table.col_old', 'col_new', 'COLUMN' - 加约束（如
DEFAULT）：用ADD CONSTRAINT，例如ALTER TABLE t ADD CONSTRAINT DF_t_col DEFAULT 0 FOR col，注意约束名不能重复
Navicat 自动生成的脚本常含 USE 和 GO，SQL Server Management Studio 可能报错
Navicat 在导出“修改表结构”的变更脚本时，默认会在开头加 USE [dbname]，并在每个 DDL 语句后插入 GO。但如果你把这段脚本粘贴进 SSMS 的查询窗口并用“执行”（F5）运行，GO 会被识别为批处理分隔符，而 USE 后如果数据库不存在或权限不足，后续所有语句都会失败；更隐蔽的问题是：某些 ALTER TABLE 操作（如改列名）必须单独成批，否则 sp_rename 无法生效。
实操建议：
- 确认当前连接上下文是否已指向目标库，若已连对，删掉脚本里的
USE [xxx]行 - 保留
GO，但确保每个GO前只有一条可独立执行的 DDL（如一个ALTER COLUMN+ 一个sp_rename必须分两个GO） - Navicat 的“同步到数据库”功能比“导出 SQL”更可靠——它会自动处理依赖顺序和事务边界，适合生产环境小范围调整
修改主键或外键列时，Navicat 不会自动禁用约束，需手动处理
Navicat 图形界面允许你直接双击主键列改类型或设为 NULL，但它不会主动 DROP 约束、也不会提示你先备份数据。结果就是执行时报错：Cannot alter column 'id' because it is used in a foreign key constraint 或 The object 'PK_table' is dependent on column 'id'。这类错误不是语法问题，而是 SQL Server 的依赖保护机制在起作用。
实操建议：
- 查依赖：运行
SELECT OBJECT_NAME(f.parent_object_id) AS table_name, c.name AS column_name FROM sys.foreign_keys AS f INNER JOIN sys.foreign_key_columns AS fc ON f.object_id = fc.constraint_object_id INNER JOIN sys.columns AS c ON fc.parent_column_id = c.column_id AND fc.parent_object_id = c.object_id WHERE f.referenced_object_id = OBJECT_ID('your_table') - 临时删外键：用
ALTER TABLE child_table DROP CONSTRAINT fk_name，改完再加回来 - 主键列改类型前，先
ALTER TABLE t DROP CONSTRAINT PK_t，改完再用ADD CONSTRAINT PK_t PRIMARY KEY (col)重建
datetime 列转 datetime2 有精度兼容风险，Navicat 默认不校验
Navicat 允许你在表设计里把 datetime 类型直接改成 datetime2(7)，看起来点保存就完事。但 SQL Server 实际执行时，如果该列已有值且含毫秒部分（如 '2023-01-01 12:34:56.123'），datetime 存储精度只有 3.33ms，转成 datetime2 后会补零或四舍五入，导致时间偏移。更麻烦的是，如果应用层代码硬编码了 datetime 的序列化格式（比如 .NET 的 DateTimeKind.Unspecified 处理逻辑），改类型后可能引发时区解析异常。
实操建议：
- 先用
SELECT TOP 10 col, CAST(col AS datetime2(7)) FROM t对比原始值和转换后值，确认无精度丢失 - 避免直接 ALTER COLUMN，改为新增
col_new datetime2(7)→UPDATE t SET col_new = col→ 校验 →DROP COLUMN col→sp_rename重命名新列 - 检查所有引用该列的视图、函数、索引，
datetime2列默认不参与旧索引，需重建
事情说清了就结束。最常被跳过的其实是依赖检查和精度验证——不是语法跑不通，而是改完才发现外键断了、时间差了 3ms、索引失效了。
