加载失败
原文案例称“C# 字符串在 Dapper 中悄悄毁掉 SQL Server 索引”，引发大量评论将焦点转向 SQL Server 的字符类型与优化器行为。讨论基于 nvarchar/varchar、collation（排序规则）、SQL Server 的数据类型优先级与参数化查询的计划缓存机制，而非单纯指责 C#。评论同时涉及 .NET 使用 UTF‑16、SQL Server 近年引入的 UTF‑8 支持及存储字节数差异，强调很多系统存在历史遗留与兼容权衡。理解这场争论需要知道 Dapper（一个 .NET micro‑ORM）、Entity Framework（.NET ORM）与 SQL Server 的类型/执行计划语义。
多位评论者指出根因不是 C# 本身，而是 SQL Server 中 nvarchar 与 varchar（或不同 collation）之间的不匹配。SQL Server 会根据数据类型优先级将较低优先级的类型提升为较高优先级（例如把 varchar 提升为 nvarchar），从而产生隐式转换。这种隐式转换会阻止原本针对列设计的索引执行 index seek，导致查询退化或使用不佳的计划。评论中也提到存储字节数差异和混合排序规则会放大问题，对实际字段是否需要 Unicode 的判断很关键。
另有评论把问题归因于 SQL Server 优化器与参数化查询的交互：数据库以参数化形式缓存执行计划，参数的类型是缓存键的一部分，因此相同 SQL 在不同参数类型下可能走不同计划或复用不合适的计划。有人认为优化器应该在绑定参数时把常量转换为目标列类型并考虑覆盖索引，但也有人指出优化器是按规则（类型优先级与缓存策略）执行的，不是随意出错。这解释了为何问题会跨语言、跨 ORM 重现，以及为何同一语句在不同环境下性能差异明显。
多个评论强调这不是 Dapper 或 C# 专有的问题：Entity Framework、其他 ORM 或不同客户端语言都会触发类似现象。特别是有评论指出 Entity Framework 在处理 null/空字符串时可能生成奇怪的谓词，导致无法利用字符串索引；Dapper 只是一个常见触发点而非根源。还有人警告不要把诊断工作外包给 LLM，否则容易把责任错误地归到表面（比如把问题标注为“C# 字符串导致”）。因此归责应集中在类型映射和数据库层面的行为上，而不是简单指向某一端技术栈。
评论中对编码选择展开争论：.NET 的 C# 字符串使用 UTF‑16，这使得客户端参数易被映射为 nvarchar，而这与某些数据库表的 varchar 列存在摩擦。有人认为大多数字段仍可用单字节编码（ASCII/ varchar），但也有人指出用户输入和多语言支持通常需要 Unicode（建议使用 UTF‑8）。评论还提到 SQL Server 在较新版本才加入 UTF‑8 支持并曾有早期问题，以及 nvarchar 的压缩和存储差异会影响设计决策。总体上，实际系统中存在历史遗留、性能权衡和版本兼容性三方面的现实约束。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
nvarchar / varchar: SQL Server 的两种字符列类型：nvarchar 存储 Unicode（通常以 UTF‑16/UCS‑2 风格，每字符占更多字节），varchar 存储基于代码页的非 Unicode 字符，存储更紧凑但不能表示所有 Unicode 字符。类型不匹配会触发隐式转换并可能导致索引不能被使用。
collation（排序规则）: 定义字符比较规则、大小写敏感性和使用的代码页或字符集；不同 collation 或混合使用会改变比较行为并可能引发隐式转换，从而影响索引和查询计划。
数据类型优先级 (data type precedence): SQL Server 在不同数据类型参与运算或比较时按优先级决定哪一边被转换。例如 nvarchar 的优先级高于 varchar，会把 varchar 提升为 nvarchar，触发隐式转换并影响索引利用。
参数化查询与计划缓存 (parameterized query / plan cache): SQL Server 缓存查询的执行计划，缓存键包含参数类型；如果参数类型与列类型不匹配或缓存复用不当，会导致选错索引或不重新规划，从而造成性能问题。
UTF-16（.NET 字符串编码）: C#/.NET 在内存中以 UTF‑16 编码表示字符串，这通常使客户端字符串映射到数据库的 nvarchar，从而与使用 varchar 的列产生不匹配风险。