主页 / dba / 问题 / 11980
Accepted
JoeGeeky
Asked: 2012-02-01 15:01:59 +0800 CST

多少存储过程参数太多了？

  • 772

我刚刚开始在 SQL Server 2008 中编写存储过程，并且有 30 多个参数。我从来没有写过一个参数超过 10 个的，这让我开始思考……什么时候参数太多了？

对于上下文......这个过程基本上将单行插入到单个表中。也会有一个非常相似的；虽然有点小；对同一张表执行UPDATE的版本。大多数列相对较小，混合了 int 和字符串 ( varchar(200))。

有什么问题；是好是坏; 拥有一个具有大量参数的程序，我应该开始考虑其他模式的阈值是多少？

sql-server-2008 database-design

2 个回答

  1. Best Answer

    问题？我不会争辩。

    • 限制为 2100 个参数。IIRC 自 SQL2000 以来一直是 2100，但文档错误表明它是 1024。
    • 如果一个表有 1000 列（例如，由于 Sharepoint 式的稀疏列排列）并且您通过存储过程强制访问，那么您的插入过程可能有 1000 个参数。没有错。
    • 当您遇到一个宽表（不是 30 是特别宽的）时，请暂停以查看架构。发现一开始生活正常化但由于懒惰和/或无能而变得面目全非的桌子并不少见。
    • 甚至不要简单地考虑将一组参数作为 CSV 列表或 XML 传递。使查询优化器失明，几乎不节省时间或精力。
    • 不要手摇客户端代码来调用具有大量参数的过程。诸如T4 模板或CodeSmith之类的代码生成工具可助您一臂之力。
    • 14

  2. Joe Celko 是长参数列表的倡导者，他在这篇 由两部分组成的文章中详细介绍了这一点：

    最简单的答案是使用长参数列表在过程主体内构造列表和派生表。SQL Server 最多可以处理 2100 个参数，对于实际用途来说应该绰绰有余。SQL Server 在这方面实际上是个懦夫；DB2 ;可以传递 32K 个参数。Oracle 可以有 64K 个参数。

    ...长参数列表由普通的旧参数组成，这意味着它们可以用于输出和输入。它也包含在优化器使用的一个语句中。

    我认为这些技术将永远是最好的解决方案吗？当然不是。SQL 中没有这样的东西。但是，当您遇到适当的问题时，值得一看。

    • 2

相关问题