SQL Server 中 IN 参数超 2100 个时应改用临时表、分批查询或表值参数方案；首选临时表，因其稳定、易用且无需额外建模。
当 IN 查询参数超过 2100 个（SQL Server 限制），Dapper 原生语法 WHERE Id IN @Ids 会直接报错——这不是 Dapper 的缺陷，而是 SQL Server 底层协议（TDS）对单条命令参数数量的硬性约束。绕过它需要改变数据传递方式，而非拼接字符串。
用临时表替代 IN 子句
这是最稳定、可扩展性最强的方案，尤其适合一次性传入数千甚至上万个 ID。
- 先创建本地临时表（
#temp_ids），结构简单，只含一列（如id INT或id UNIQUEIDENTIFIER） - 用
connection.Execute()批量插入 ID（支持IEnumerable直接传入） - 改写原查询为
JOIN #temp_ids或WHERE EXISTS (SELECT 1 FROM #temp_ids t WHERE t.id = main.id) - 临时表生命周期自动绑定连接，无需手动清理
分批执行 IN 查询
适用于 ID 集合可预知、且总数量在数万以内，逻辑简单、改动最小。
- 将大数组按每批 ≤ 2000 个切分（留余量防边界问题）
- 循环调用
Query(sql, new { Ids = batch}) - 合并结果可用
Concat()或List，注意内存累积.AddRange() - 若需去重或排序，建议在应用层统一处理，避免多次数据库排序
用 EXISTS + 表值参数（TVF）或用户定义表类型（UDT）
SQL Server 专属高级方案，性能接近原生 JOIN，但需提前建模。
- 在数据库中定义表类型，例如：
CREATE TYPE dbo.IntList AS TABLE (Value INT) - C# 中构造
DataTable，添加列并填充 ID 数据 - 用
new SqlServerTypes.StructuredUserDefinedTypeParameter(……)或 Dapper+SqlMapperExtensions 封装为参数 - SQL 中写成：
WHERE EXISTS (SELECT 1 FROM @IdsTable t WHERE t.Value = main.Id) - 比临时表少一次往返，但部署和维护成本略高
不推荐的做法
这些看似“快捷”的方式实际隐患明显：
- 字符串拼接 SQL：触发 SQL 注入、执行计划无法复用、易出语法错误
- 把 IN 改成 OR 链 ：SQL 解析慢、计划缓存爆炸、超出最大表达式深度
- 盲目增大 CommandTimeout：掩盖问题而非解决，可能拖垮连接池
基本上就这些。核心思路很明确：把“参数太多”这个问题，从“传参”转移到“数据落地”，让数据库自己做匹配。临时表方案上线快、兼容好，大多数业务场景首选它。
