有几个答案给予了你关于AddWithValue的警告。这些twolinks通常给出。我得到的印象是，这是危险的，因为AddWithValue必须猜测C#数据的SQL类型，导致使用错误的查询计划。然而，在我的用例中，几乎所有的参数都是C#中的int，它们被传递给SQL中的参数化存储过程。我无法想象有多少错误的SQL猜测C# int可能是什么类型。
以上是否意味着我没有使用AddWithValue的性能风险？如果是这样的话，我已经自由了，因为AddWithValue只在C#中是危险的吗？或者我已经自由了，因为使用存储过程而不是参数化查询已经节省了时间？
1条答案
按热度按时间jv4diomz1#
ADO.NET总是要猜测你的参数类型，但是有些类型总是有固定的Map。
下列参数类型可能会有问题
(n)(var)char(var)binarydecimalfloatreal(small)money(small)(date)(time)(2/offset)刚才提到的这些问题不仅仅是因为参数类型，而且还因为长度/精度/刻度。
其他类型，如
int，可能与您传入的类型不匹配，建议您始终使用正确的类型以防万一。是的，int确实总是Map到int，但其他许多对象并不Map。最好养成总是指定它的习惯。以上是否意味着我没有使用AddWithValue的性能风险？
是的，在那个特定的情况下，但我还是不会这么做。
如果是这样，我已经自由了，因为AddWithValue只对C#字符串有危险吗？
不，如前所述，还有其他有问题的数据类型。
或者我已经自由了，因为使用存储过程而不是参数化查询已经节省了时间？
存储过程会自动将您发送 * 回 * 的内容转换为正确的数据类型，这只会带来很小的开销。在某些数据类型的情况下，可能会丢失数据（精度或某些字符）。例如，如果您将
nvarchar作为varchar传递，则扩展字符集可能会完全丢失，并且过程在这里没有帮助。