首先，我理解主键在SQL表上的作用，或者任何数据库中的作用。
然而，当涉及到用户定义表类型时，我发现自己无法理解为什么要创建一个主键。 根据我的经验，我没有发现它们的性能优势，但我怀疑我的发现可能来自于我对它们的一般使用和有限的经验，而不是更有经验的观点。
例如，我一般在插入更新过程中使用表值参数，或者在创建选择查询时传递一个值的数组。 我没有发现它们对性能有什么好处，如果有的话，我经历了一个小的性能下降（但我们说的是最多10几毫秒，所以可以忽略不计）。
我应该透露的是，在它们内部传递的任何数据都已经被精心清理过了，所以有可能我并没有因此看到好处，但我没有办法轻易知道。
因此，问题又来了，我是否应该在我的用户定义表类型上设置一个主键，还是说它并不那么重要？
如果这是一个重复的问题，请原谅。 我做了大量的搜索，但我可能使用了错误的关键字组合。
您的见解将一如既往地得到极大的赞赏。
事实上，我也对同样的事情感到好奇，但从不同的角度来看......。
我们有一个动态查询，由用户输入的信息组合成一个查询，结果是这样的。
"SELECT A.*
FROM A
<some joins, etc>
WHERE A.ID IN ('" + String.Join("','", List<UserInputs>) + "')"
我想用tvp关闭sql注入的漏洞，但是查询性能完全下降了（慢了好几个数量级）。
有字面意义的计划从一个漂亮的、干净的索引扫描id列开始，速度非常快。
而使用TVP的计划在进入选择部分之前，连接到TVP并将整个表具体化，变得非常复杂。
我在想，如果在tvp类型上加一个主键，可能会让优化器生成一个更好的计划。
如果你传递的数组是一个id的数组，要在与其他表的join上直接匹配，那么有一个集群的主键就很有意义。
为了避免在插入之前花时间对数据进行排序，你应该在应用端已经对数据进行了排序。
在这种情况下，我经历了大约400ms的收益。
这要根据具体情况来评估。
你可以在用户定义的表类型上创建主键，从而形成聚类索引，但不可能在用户定义的表类型上创建非聚类索引。
关于你的信息，请看下面的页面
http:/technet.microsoft.comen-uslibrarybb522526(v=sql.105).aspx。