文章揭示了C#字符串类型与Dapper结合使用时，会隐式转换为SQL Server的NVARCHAR类型，导致索引失效，引发严重的性能问题。这种类型不匹配在代码中难以察觉，却可能造成CPU使用率飙升和查询速度大幅下降。

标题：C#字符串如何悄无声息地破坏Dapper中的SQL Server索引性能

主要内容： 1. 问题现象
作者在排查生产环境性能问题时发现，一个简单的Dapper查询（通过索引列筛选）消耗了大量CPU资源。根本原因是C#字符串参数默认映射为nvarchar(4000)，而数据库列类型为varchar，导致SQL Server执行隐式转换（CONVERT_IMPLICIT），无法使用索引，引发全表扫描。

2. 性能影响

   • 正确类型下（varchar参数）：索引查找（Index SEEK），微秒级响应
   • 类型不匹配时（nvarchar参数）：索引扫描（Index SCAN），逻辑读取数激增
   • 实际案例中，单日数十万次查询导致数据库CPU持续高负载

3. 解决方案

   • 使用DynamicParameters显式指定DbType.AnsiString（对应varchar）： csharp parameters.Add("productCode", productCode, DbType.AnsiString, size: 100);
   • 或通过DbString简写： csharp new DbString { Value = productCode, IsAnsi = true, Length = 100 }

4. 优化效果
   | 指标 | 优化前（nvarchar） | 优化后（varchar） | |------------|-------------------|-------------------| | 扫描类型 | 索引扫描 | 索引查找 | | 逻辑读取 | 数万次 | 个位数 | | CPU耗时 | 毫秒级 | 微秒级 |

5. 排查建议

   • 检查SQL Server查询存储中包含@%nvarchar(4000)%的高CPU查询
   • 在执行计划中搜索CONVERT_IMPLICIT警告
   • 审查代码中通过匿名对象传递字符串参数的Dapper调用

6. 最佳实践

   • varchar列必须使用DbType.AnsiString
   • 添加代码注释防止后续误改： csharp // 必须指定AnsiString，避免隐式转换导致索引失效

7. 扩展阅读
   推荐参考微软官方文档中关于ADO.NET数据类型、SQL Server查询处理架构以及数据类型转换的说明。

（注：原文中的作者介绍、社交媒体链接、导航菜单等非技术内容已精简，保留核心技术分析和解决方案。）

以下是评论内容的总结：

1. 数据类型选择问题
   评论认为问题源于使用varchar而非nvarchar（Unicode与ASCII的选择），并指出在2026年仍使用varchar可能仅出于向后兼容性考虑。

   • "This is your classic nvarchar vs varchar issue" (wvenable)
   • "Who on earth creates databases in Latin1 in 2026?" (downsplat)

2. SQL查询优化器或Dapper的潜在问题
   部分评论认为这是SQL查询优化器的缺陷，而非Dapper的问题，优化器应能自动转换参数类型以利用索引。

   • "This feels like a bug in the SQL query optimizer" (jiggawatts)
   • "I never had this issue with Dapper... an holding it wrong problem" (pjmlp)

3. 对AI生成内容的批评
   多位评论者批评文章由AI生成，缺乏具体基准测试数据，且文风令人不适。

   • "The AI adds nothing here but the same annoying old AI-isms" (mvdtnz)
   • "no meaningful benchmarking was done" (bunbun69)

4. 解决方案建议
   有评论提出通过配置Dapper默认映射或使用存储过程来解决类型不匹配问题。

   • "Dapper.SqlMapper.AddTypeMap(typeof(string),System.Data.DbType.AnsiString)" (briHass)
   • "use stored procedures... a defined interface for the database" (briHass)

5. 对SQL Server的负面评价
   个别评论表达了对SQL Server的不满，认为其仍存在固有缺陷。

   • "Life is too short to use SQL Server... yes it is [bad]" (ltbarcly3)

6. 第三方依赖的复杂性
   评论指出第三方工具（如Dapper）的实际使用需深入了解其实现细节，并非“即插即用”。

   • "you just have to intimately know how it is implemented" (elmigranto)

7. 字符编码问题的争议
   部分评论提及UTF-16和遗留编码（Latin1）的问题，批评SQL Server对UTF-8支持较晚。

   • "This is due to utf-16, an unforgivable abomination" (enord)
   • "Sql Server didn't add utf8 collations until 2019" (downsplat)

总结呈现了技术讨论（数据类型、优化器）、工具批评（AI、SQL Server）及解决方案的多角度观点，保留了原始评论的关键引用。