直接复制存储过程常失败，因sp_helptext返回不完整、缺CREATE头和GO分隔、未转义特殊字符、忽略依赖项；应改用sys.sql_modules查definition，验证参数类型兼容性，并检查执行权限。
直接复制存储过程在多数情况下会失败——不是语法报错，就是执行时找不到依赖对象或权限不足。核心问题不在“怎么导出”，而在于“导出后怎么让它在目标库真正跑起来”。
SQL Server 中用 sp_helptext 提取定义但不完整
很多人第一反应是用 sp_helptext 查看存储过程内容，再手动粘贴到新库执行。这看似简单，实际踩坑很多：
-
sp_helptext对超过 4000 字符的定义会分多行返回，手工拼接容易丢段落或换行符 - 它不带
CREATE PROCEDURE开头和GO分隔，直接执行会报错Incorrect syntax near 'AS' - 不处理对象名中的特殊字符（比如含中括号、空格、连字符），
sp_helptext返回的名称没做转义，粘贴过去可能触发Invalid object name - 不检查依赖项：如果该存储过程里调用了另一个未迁移的存储过程或自定义函数，执行时直接失败
用 sys.dm_exec_describe_first_result_set 验证参数兼容性
即使存储过程成功创建，调用时也可能因参数类型差异崩溃。尤其跨版本（如 SQL Server 2016 → Azure SQL）或跨平台（→ MySQL）时，datetime2、hierarchyid、xml 等类型未必被支持。
迁移前建议跑一次验证：
SELECT parameter_ordinal, parameter_name, system_type_name, is_nullable FROM sys.dm_exec_describe_first_result_set(N'EXEC [源库].[dbo].[proc_name]', NULL, 0) WHERE parameter_ordinal > 0;
重点关注：
-
system_type_name是否在目标库存在对应类型（例如 Azure SQL 不支持sql_variant） -
is_nullable与目标库默认值策略是否冲突（如新库启用了ANSI_NULLS ON强制要求） - 输出参数若含表值类型（TVP），需确认目标库是否支持（Azure SQL 支持，MySQL 完全不支持）
绕过 syscomments 直接读 sys.sql_modules
老教程常教用 syscomments 表提取文本，但它在 SQL Server 2005+ 已被弃用，且对加密存储过程返回空值。正确做法是查 sys.sql_modules：
SELECT definition FROM [源库].sys.sql_modules m JOIN [源库].sys.objects o ON m.object_id = o.object_id WHERE o.type = 'P' AND o.name = 'proc_name';
注意三点：
- 返回的
definition是 NVARCHAR(MAX)，已含完整CREATE PROCEDURE语句，无需手动补头尾 - 若存储过程被加密（
is_encrypted = 1），此查询返回 NULL——此时只能靠备份还原或 SSMS 脚本向导导出（且需原库有VIEW DEFINITION权限） - 执行前务必用
USE [目标库]切换上下文，否则CREATE PROCEDURE默认建在master下
最易被忽略的是权限链：即使存储过程创建成功，执行时仍可能报 The SELECT permission was denied on the object——因为目标库中执行者没有对被引用表的权限。别只盯着“能不能建”，得验证“能不能跑”。
