sp_rename重命名列必须显式指定'column'参数，否则可能误操作为重命名表或视图；正确写法为exec sp_rename 'schema.table.column', 'new_name', 'column'，且执行后警告不可忽略。
sp_rename 重命名列必须带 'COLUMN' 类型参数
SQL Server 中漏掉第三个参数 'COLUMN' 会导致命令静默失败或误操作成重命名表/视图。比如执行 EXEC sp_rename 'users.name', 'full_name'，系统会按 'OBJECT' 类型处理，若恰好存在同名视图，就可能把视图改名了。
正确写法必须显式指定类型和完整路径：
-
EXEC sp_rename 'users.name', 'full_name', 'COLUMN'—— 表名和旧列名之间用点号连接，新列名不能带表名 - 若表在非默认 schema（如
dbo），必须写全：EXEC sp_rename 'dbo.users.name', 'full_name', 'COLUMN' - 执行后会输出警告
Caution: Changing any part of an object name could break scripts...，这不是可忽略的提示，是真实风险信号
ALTER COLUMN 修改默认值要先删再加
SQL Server 不支持直接用 ALTER COLUMN 更新默认值；必须先删除原有默认约束，再新建一个。因为默认值是以独立约束形式存在的，不是列定义的一部分。
步骤如下：
- 查出当前默认约束名：
SELECT name FROM sys.default_constraints WHERE parent_object_id = OBJECT_ID('users') AND parent_column_id = COLUMNPROPERTY(OBJECT_ID('users'), 'full_name', 'ColumnId') - 删掉它：
ALTER TABLE users DROP CONSTRAINT [DF__users__name__...]（实际名需从上步查得） - 新加默认值：
ALTER TABLE users ADD CONSTRAINT DF_users_full_name DEFAULT 'N/A' FOR full_name
注意：DEFAULT 'N/A' 中的字符串必须用单引号，不能用双引号；数值不用引号；函数如 GETDATE() 也不加引号。
MySQL 和 PostgreSQL 的列重命名 + 默认值要分两步走
MySQL 的 CHANGE 语法强制你重写整列定义，稍不注意就会丢掉默认值或 NOT NULL 约束：
- 错例：
ALTER TABLE users CHANGE name full_name VARCHAR(100)—— 原来的NOT NULL DEFAULT 'guest'全丢了 - 对例：
ALTER TABLE users CHANGE name full_name VARCHAR(100) NOT NULL DEFAULT 'guest'—— 必须原样复述所有属性
PostgreSQL 更友好，但默认值仍要单独处理：
- 先重命名：
ALTER TABLE users RENAME COLUMN name TO full_name - 再改默认值：
ALTER TABLE users ALTER COLUMN full_name SET DEFAULT 'guest'（或DROP DEFAULT）
它不会自动继承原默认值，即使你没显式 DROP，新列也默认没有默认值。
重命名后依赖对象不会自动更新
无论哪种数据库，sp_rename 或 ALTER TABLE ... RENAME COLUMN 都只改元数据，不碰视图、存储过程、触发器里的 SQL 文本。
常见报错包括：
-
Invalid column name 'name'（触发器里还引用旧列名） -
Invalid object name 'users'（如果同时重命名了表，而视图里写死旧表名） - 非架构绑定视图中用了
SELECT *，查询结果列名仍是旧的，客户端可能解析失败
补救方法只有两个：手动搜改所有依赖对象，或用 sp_refreshview（SQL Server）刷新视图元数据——但它不修复文本中的硬编码列名。
真正容易被忽略的是：外键约束名、索引名、统计信息名都不会变，但它们内部指向的列已经换名了，后续 UPDATE STATISTICS 或重建索引时可能出意外。
