ALTER SCHEMA ... TRANSFER 是唯一安全方式，需先创建目标schema、确保权限、排除自身及系统对象、生成语句审核后再执行，并备份数据库以防回退。
直接用 ALTER SCHEMA ... TRANSFER 是唯一安全方式
SQL Server 不允许直接重命名 schema，也不能用 UPDATE sys.schemas 这类操作绕过校验。所有“批量改 schema”的本质，都是对每个对象逐条执行 ALTER SCHEMA [new] TRANSFER [old].[obj]。存储过程只是帮你生成并执行这些语句的自动化工具，不是魔法开关。
必须提前确认新 schema 已存在且授权正确
如果 [LC039999] 还没创建，或用户没有该 schema 的 CONTROL 权限，ALTER SCHEMA ... TRANSFER 会报错：Cannot find the object "xxx", because it does not exist or you do not have permission.
- 先运行
CREATE SCHEMA [LC039999] AUTHORIZATION [LC039999];（注意：schema 名和 owner 用户名最好一致） - 确保当前执行账号是
db_owner，或至少对旧 schema 有TAKE OWNERSHIP、对新 schema 有CONTROL - 检查目标 schema 下不能已存在同名对象，否则报错：
The specified schema or object does not exist.
存储过程里要过滤掉自身和系统对象
常见翻车点：游标或动态 SQL 没排除存储过程自己，导致执行时试图把 upx_changeSchema 从 dbo 转到新 schema，而它正被调用中，引发死锁或元数据不一致。
- 在
SELECT ... FROM sys.objects里加条件：AND [object_id] != OBJECT_ID('dbo.upx_changeSchema') - 类型过滤只留业务对象：
WHERE type IN ('U', 'V', 'P', 'FN', 'IF', 'TF')（表、视图、存储过程、各类函数） - 别漏掉依赖对象：主外键、索引、约束会随表自动迁移，但同名同 schema 的同义词（
Synonym）或序列（SEQUENCE）需单独处理
生成语句 vs 直接执行：选哪种更稳妥？
推荐先生成语句再人工审核，而不是在存储过程中 EXEC(@sql) 一把梭。尤其当跨 schema 涉及权限变更或应用连接字符串硬编码了 dbo.Table 时，贸然执行可能让应用直接报错。
- 用
SELECT 'ALTER SCHEMA ...' + s.name + '.' + o.name生成完整语句列表，复制到新窗口手动执行 - 若坚持自动执行，务必加事务 + TRY/CATCH：
BEGIN TRY ... EXEC(@sql) ... COMMIT ... END TRY BEGIN CATCH ROLLBACK ... END CATCH - 执行前必须备份：哪怕只是
BACKUP DATABASE [Northwind] TO DISK = '...'，否则出错无法回退
sys.objects 里的隐式依赖——比如某个视图引用了 dbo.TableA，而你只改了表的 schema 却没同步改视图定义，视图就会失效。这类问题不会在 ALTER SCHEMA 阶段报错，但查询时才暴露。 
