Azure SQL中使用AddWithValue时datetime2插入与查询不匹配问题

这个问题的核心在于AddWithValue方法的隐式类型推断，以及.NET DateTime与SQL Server datetime2类型之间的精度差异。

1. AddWithValue的类型推断问题 #

当你使用command.Parameters.AddWithValue("@Date", date)时，.NET会根据传入的DateTime对象自动推断SQL参数类型。在.NET Core 2.2中，这个推断结果是SqlDbType.DateTime（对应SQL Server的datetime类型），而不是你数据库列使用的SqlDbType.DateTime2。

两者的精度差异极大：

• SqlDbType.DateTime（SQL datetime）的精度只有3.33毫秒（即1/300秒，只能表示.000、.003、.007这类小数位）
• SqlDbType.DateTime2（SQL datetime2）支持100纳秒的精度，和.NET DateTime的原生精度完全匹配

2. 插入与查询的精度错位 #

当你执行插入时：

• 你传入的.NET DateTime值是19:33:22.7727095（高精度），但因为参数被推断为SqlDbType.DateTime，SQL Server会将其转换为最接近的datetime精度值——也就是19:33:22.7733333（对应1/300秒的近似值），然后存储到datetime2列中（此时列会完整保留这个转换后的值）。

当你执行查询时：

• 你使用了同一个.NET DateTime对象，但AddWithValue仍然推断参数为SqlDbType.DateTime。此时SQL Server会将列中的datetime2值（19:33:22.7733333）与参数的datetime值（19:33:22.7727095转换后的近似值）进行比较。由于datetime和datetime2的精度规则不同，两者的二进制表示并不完全匹配，导致查询无法找到对应数据。

而当你再次执行插入时，SQL Server会检查主键约束，发现数据库中已经存在转换后的datetime2值，因此抛出主键重复错误。

3. 为什么显式指定SqlDbType.DateTime2能解决问题？ #

当你使用command.Parameters.Add("@Date", SqlDbType.DateTime2).Value = date;时，参数类型被明确指定为datetime2，和数据库列的类型完全一致：

• 插入时，.NET DateTime的高精度值会被完整传递并存储到datetime2列中
• 查询时，参数的高精度值与列中的存储值完全匹配，因此能正确找到数据

最佳实践 #

永远避免依赖AddWithValue的隐式类型推断——它不仅会导致日期精度问题，还可能引发字符串长度截断、数值类型不匹配等一系列潜在问题。显式指定参数的类型、长度（如果需要）是更安全的做法：

// 推荐写法
command.Parameters.Add("@Id", SqlDbType.Int).Value = 1;
command.Parameters.Add("@Date", SqlDbType.DateTime2).Value = date;

内容的提问来源于stack exchange，提问作者Carlos Barroso