执行存储过程提示“对象名无效”大概率因未写schema前缀，sql server不会自动fallback到dbo；需显式指定如exec dbo.getuserinfo，并排查权限、跨库、rds元数据同步等问题。
执行存储过程时提示“对象名无效”，大概率是没写 schema 前缀
SQL Server 默认不自动解析未带架构的存储过程名，哪怕它就在 dbo 下。比如你写了 EXEC GetUserInfo，SQL Server 会先在当前用户默认 schema（可能不是 dbo）里找，找不到就直接报错，不会 fallback 到 dbo。
解决方法很简单：显式加上 schema 名。
-
EXEC dbo.GetUserInfo—— 大多数情况用这个就够了 -
EXEC YourDB.dbo.GetUserInfo—— 跨库调用时必须写全三段名 - 别用
EXEC [GetUserInfo]或EXEC 'GetUserInfo'，方括号只用于转义，单引号是字符串字面量，会报语法错误
为什么 INFORMATION_SCHEMA.ROUTINES 查不到你的存储过程
查不到 ≠ 存储过程不存在，更可能是你查的数据库不对，或者它不在当前 schema 下。
用下面这句才可靠：
SELECT ROUTINE_NAME, ROUTINE_SCHEMA, ROUTINE_TYPE FROM INFORMATION_SCHEMA.ROUTINES WHERE ROUTINE_NAME = 'GetUserInfo';
注意点：
- 结果为空？先确认
USE YourDatabase;是否已执行 - 查到了但
ROUTINE_SCHEMA是test而不是dbo？那就要用EXEC test.GetUserInfo -
INFORMATION_SCHEMA视图不显示系统存储过程，也不显示被加密的（WITH ENCRYPTION）存储过程
权限不足也会触发“对象名无效”，而不是“拒绝访问”
这是 SQL Server 的一个反直觉行为：如果用户对某个存储过程没有 EXECUTE 权限，SQL Server 不会说“你没权限”，而是假装“这东西根本不存在”，抛出 Invalid object name。
验证权限的最快方式：
SELECT * FROM fn_my_permissions('dbo.GetUserInfo', 'OBJECT');
如果结果里没有 EXECUTE 行，就说明权限缺失。补权限用：
GRANT EXECUTE ON dbo.GetUserInfo TO [YourUser];- 或加到角色：
ALTER ROLE db_executor ADD MEMBER [YourUser];（需提前创建该角色）
RDS 或低权限环境里，sp_rename 改名后仍报错
在阿里云 RDS、Azure SQL 等托管环境中，sp_rename 可能只改了名字，但没同步更新依赖元数据，尤其当原存储过程引用了其他库/Schema 的对象时。
此时即使名字对了、schema 对了、权限也给了，执行仍报“对象名无效”。排查重点：
- 检查存储过程中所有
SELECT/UPDATE语句里的表名，是否也都带了完整 schema（如dbo.Orders），不能只写Orders - 用
sys.dm_exec_describe_first_result_set查依赖：SELECT * FROM sys.dm_exec_describe_first_result_set(N'EXEC dbo.GetUserInfo', NULL, 0);
看是否有 unresolved reference - 最稳妥的办法：
DROP PROCEDURE后重新CREATE，避免元数据残留
真正容易被忽略的是：错误信息本身不区分“真不存在”和“有权限但查不到”。同一句报错，背后可能是拼写错、schema 漏写、跨库未指定、权限缺失、甚至 RDS 元数据不同步——得一层层排除，不能只盯着名字看。
