SQL Server存储过程无法限制单个调用的并发连接数，因其运行在客户端会话上下文中，不拥有或控制连接；真正可行的是通过Resource Governor设置工作负载组MAX_REQUESTS限制并发执行数，或在应用层用分布式锁/队列实现限流。
SQL Server 存储过程中无法直接限制“单个调用”的并发连接数——因为连接（connection）是客户端会话级的资源，不是存储过程能控制的粒度。你真正能干预的，是该存储过程执行时占用的并行度（parallelism）、会话资源上限、或通过外部机制限制其被并发调用的频率。
为什么不能在存储过程里设“最大连接数”
连接由客户端应用程序发起，sp_configure 'user connections' 是实例级全局配置，影响所有登录；而一个存储过程运行在某个已建立的连接上下文中，它本身不“拥有”连接，也无法决定这个连接是否被复用或新建。常见误解是想让 EXEC my_proc 同时最多只跑 3 个实例——这不属于连接数控制，而是并发执行控制。
- 存储过程没有独立生命周期或连接池概念
-
@@connections和sys.dm_exec_sessions统计的是会话总数，不是某 proc 的“调用数” - 试图在 proc 内部用
sp_who或sys.sysprocesses查自己被调了多少次，既不可靠（竞争条件），也无实际限流能力
替代方案：用资源调控器（Resource Governor）限制工作负载组并发
这是 SQL Server 原生支持的、最贴近你需求的方式：把调用该存储过程的会话归类到特定工作负载组，再限制该组的最大并发请求（MAX_DOP 和 REQUEST_MAX_MEMORY_GRANT_PERCENT 是辅助项，核心是 MAX_REQUESTS）。
- 先创建资源池：
CREATE RESOURCE POOL proc_pool WITH (MAX_CPU_PERCENT = 30, MAX_MEMORY_PERCENT = 25); - 再建工作负载组并绑定到池：
CREATE WORKLOAD GROUP proc_group USING proc_pool; - 写分类函数，按
PROGRAM_NAME()或ORIGINAL_LOGIN()匹配你的调用方（例如 AppName='OrderService'），返回'proc_group' - 启用 Resource Governor：
ALTER RESOURCE GOVERNOR RECONFIGURE; - 关键点：
MAX_REQUESTS参数在工作负载组中控制“同时处于 active 状态的请求数”，这才是你想要的“单个存储过程最多并发执行 N 次”的等效机制
更轻量的实践：应用层加分布式锁或队列
如果 Resource Governor 配置太重或权限受限，推荐把限流逻辑下沉到应用层。GaussDB 的 CREATE SQL_LIMIT RULE 或 MySQL 的 max_connections 用户级限制都不适用于“单个存储过程”，但你可以：
- 在调用前，用 Redis SETNX + EXPIRE 实现每秒最多 N 次调用（基于 SQL 指纹哈希）
- 用消息队列（如 RabbitMQ）削峰，让消费者端控制并发消费数
- 在 GORM 等 ORM 中，对调用该 proc 的 DAO 方法加
semaphore.Acquire()（Go）或asyncio.Semaphore(3)（Python） - 避免在 proc 内部尝试
WAITFOR DELAY或轮询sys.dm_exec_requests—— 这会导致阻塞放大和 CXPACKET 等待飙升
容易踩的坑：混淆 max degree of parallelism 和连接数
很多人看到 sp_configure 'max degree of parallelism', 1 就以为“限制了并发”，但它只禁用查询级并行（即不让一条 SELECT 自动拆成多线程执行），跟“多少人能同时调用这个存储过程”完全无关。同样，user connections = 10 是整个实例最多接受 10 个连接，不是给某个 proc 分配 10 个额度。
-
max degree of parallelism = 1→ 防止单条语句抢 CPU，不防高并发调用 -
user connections = 10→ 可能连sa都登不上，管理风险极高 -
SET LOCK_TIMEOUT 5000在 proc 内部设超时，只能缩短失败等待时间，不能阻止并发发生
真正要控“单个存储过程的并发调用数”，必须跳出连接数思维，转到资源组或应用协调层。否则，所有 T-SQL 内部操作都只是打补丁，治标不治本。
