c# - 为什么 `nvarchar` 参数比 'text' `SqlCommand` 命令的其他类型更快？

Question

概览

这个问题是这个问题的更具体的版本:

• sql server - performance hit when passing argument of C# type Int64 into T-SQL bigint stored procedure parameter

但我注意到其他数据类型也有同样的性能损失(事实上，在我的例子中，我根本没有使用任何 bigint 类型)。

这里还有一些其他问题，似乎应该涵盖这个问题的答案，但我观察到的结果与它们所表明的相反:

• c# - When should "SqlDbType" and "size" be used when adding SqlCommand Parameters? - Stack Overflow
• .net - What's the best method to pass parameters to SQLCommand? - Stack Overflow

上下文

我有一些用于将数据插入表中的 C# 代码。代码本身是数据驱动的，因为一些其他数据指定了数据应该插入到的目标表。因此，虽然我可以在存储过程中使用动态 SQL，但我选择在我的 C# 应用程序中生成动态 SQL。

对于我插入的行，命令文本总是相同的，所以我在插入任何行之前生成一次。命令文本的形式为:

INSERT SomeSchema.TargetTable ( Column1, Column2, Column3, ... )
VALUES ( SomeConstant, @p0, @p1, ... );

对于每个插入，我创建一个 SqlParameter 对象数组。

对于 'nvarchar' 行为，我只是使用 SqlParameter(string parameterName, object value) 构造方法，并没有显式设置任何其他属性。

对于“退化”行为，我使用了 SqlParameter(string parameterName, SqlDbType dbType) 构造方法，还设置了 Size、Precision 和 Scale 属性。

对于这两个版本的代码，传递给构造函数方法或单独分配给 Value 属性的值都具有 object 类型。

“nvarchar”版本的代码大约需要 1-1.5 分钟。 “退化”或“特定类型”代码需要超过 9 分钟；所以慢了 6-9 倍。

SQL Server Profiler 没有揭示任何明显的罪魁祸首。特定于类型的代码正在生成看起来更好的 SQL，即一个动态 SQL 命令，其参数包含适当的数据类型和类型信息。

假设

我怀疑，因为我将 object 类型的值作为参数值传递，所以 ADO.NET SQL Server 客户端代码在生成和发送之前正在转换、转换或以其他方式验证该值到 SQL Server 的命令。令我惊讶的是，从 nvarchar 到 SQL Server 必须执行的每个相关目标表列类型的转换比客户端代码执行的任何操作都快得多。

注意事项

我知道 SqlBulkCopy 可能是插入大量行的最佳性能选项，但我更好奇为什么 'nvarchar' 的情况 -执行“特定于类型”的情况，考虑到它通常处理的数据量，我当前的代码已经足够快了。

Answer 1

答案确实取决于您运行的数据库，但它与字符编码过程有关。 SQL Server 引入了 NVarChar 和 NText 字段类型来处理 UTF 编码数据。 UTF 也恰好是 .NET CLR 的内部字符串表示形式。 NVarChar 和 NText 不必转换为另一种字符编码，这需要很短但可衡量的时间。

其他数据库允许您在数据库级别定义字符编码，而其他数据库则允许您逐列定义。性能差异实际上取决于驱动程序。

同样重要的是要注意:

• 使用准备好的语句插入强调转换为数据库内部格式的效率低下
• 这与数据库查询字符串的效率无关——UTF-16 比 Text 和 VarChar 的默认 Windows-1252 编码占用更多空间。
• 当然，在全局应用中，UTF的支持是必须的