Dapper y SQL Server: el bug nvarchar que mata tus indices

El problema silencioso que destruye tus índices en SQL Server

Si tu aplicación .NET usa Dapper para consultar SQL Server y tus columnas son de tipo varchar, hay una trampa de rendimiento que probablemente está ejecutándose en producción ahora mismo — sin ningún error, sin ninguna advertencia, y con resultados completamente correctos. Solo más lento. Mucho más lento.

El problema se llama CONVERT_IMPLICIT, y nace de un mismatch de tipos entre C# y SQL Server que pasa completamente desapercibido en el código. En aplicaciones SaaS con alta concurrencia, este bug silencioso puede traducirse en CPU al 90%, costos de nube desbordados y experiencia de usuario degradada — todo por una diferencia de dos letras: nvarchar vs varchar.

Por qué Dapper envía nvarchar(4000) por defecto

Cuando pasas un parámetro string a Dapper usando un objeto anónimo — el patrón más común en cualquier proyecto .NET — así:

const string sql = "SELECT * FROM Products WHERE ProductCode = @productCode";
var result = await connection.QueryFirstOrDefaultAsync<Product>(sql, new { productCode });

Dapper lo mapea al tipo ADO.NET DbType.String, que SQL Server interpreta como nvarchar(4000). Este es el comportamiento predeterminado de System.String en ADO.NET, y tiene sentido como valor seguro en contextos Unicode. El problema aparece cuando la columna en la base de datos es varchar (no Unicode).

En ese momento, SQL Server enfrenta un conflicto de tipos: tiene un parámetro nvarchar y una columna varchar. Según las reglas de precedencia de tipos de datos, nvarchar tiene mayor precedencia que varchar, así que SQL Server convierte cada valor de la columna a nvarchar antes de hacer la comparación. Eso se ve así en el plan de ejecución:

CONVERT_IMPLICIT(nvarchar(255), [Sales].[ProductCode], 0)

Esa línea significa: «Tenía un índice perfecto, pero convertí cada fila antes de comparar, así que no pude usarlo.» El resultado es un Index Scan en lugar de un Index Seek.

¿Cuánto daño hace realmente CONVERT_IMPLICIT?

La diferencia entre un Index Seek y un Index Scan no es marginal — es exponencial conforme crece tu tabla.

Métrica	Antes (nvarchar)	Después (varchar)
Tipo de operación	Index SCAN	Index SEEK
Lecturas lógicas	Decenas de miles	Un dígito
CPU por ejecución	Milisegundos	Microsegundos
Impacto en servidor	CPU al 50-90%	Carga normal

En producción, esto se traduce en una query simple con cláusula WHERE sobre una columna indexada que promediaba miles de milisegundos de CPU en cientos de miles de ejecuciones diarias. No por lógica compleja. No por falta de índices. Solo por un mismatch de tipos.

Un análisis de Microsoft Azure DB Support confirma que las conversiones implícitas son una de las causas más comunes de degradación de rendimiento en aplicaciones .NET conectadas a Azure SQL y SQL Server on-premises, siendo especialmente graves en aplicaciones de alta concurrencia como SaaS multi-tenant.

La solución: DynamicParameters y DbType.AnsiString

El fix es elegante en su simplicidad. Solo necesitas decirle a Dapper explícitamente que el parámetro es varchar, no nvarchar. Esto se logra con DynamicParameters y el tipo DbType.AnsiString:

const string sql = "SELECT * FROM Products WHERE ProductCode = @productCode";

var parameters = new DynamicParameters();
// DbType.AnsiString requerido: Products.ProductCode es varchar(100).
// Sin esto, Dapper envía nvarchar(4000) y provoca CONVERT_IMPLICIT en cada fila.
parameters.Add("productCode", productCode, DbType.AnsiString, size: 100);

var result = await connection.QueryFirstOrDefaultAsync<Product>(sql, parameters);

El parámetro size debe coincidir exactamente con la definición de la columna en la base de datos. Si tu columna es varchar(255), usa size: 255. Esto no solo corrige el tipo — también ayuda a SQL Server a reutilizar planes de ejecución cacheados más eficientemente.

Alternativa con DbString

Si prefieres mantener la sintaxis de objetos anónimos, Dapper ofrece DbString como alternativa concisa:

var result = await connection.QueryFirstOrDefaultAsync<Product>(sql,
    new { productCode = new DbString { Value = productCode, IsAnsi = true, Length = 100 } });

Ambos enfoques producen el mismo resultado: un parámetro varchar en lugar de nvarchar. La elección entre DynamicParameters y DbString es principalmente de preferencia de estilo — lo importante es que IsAnsi = true esté presente para columnas varchar.

Cómo detectar este problema en tu aplicación

Lo más peligroso de este bug es que es invisible: el código luce correcto, la query devuelve resultados correctos, y no hay errores en los logs. Aquí hay tres formas concretas de detectarlo:

1. Query Store — identificar conversiones implícitas

Ejecuta esta consulta en tu base de datos para encontrar las queries más costosas con el patrón de nvarchar(4000):

SELECT TOP 20
    qsqt.query_sql_text,
    qsrs.avg_cpu_time,
    qsrs.count_executions
FROM sys.query_store_runtime_stats qsrs
JOIN sys.query_store_plan qsp ON qsrs.plan_id = qsp.plan_id
JOIN sys.query_store_query qsq ON qsp.query_id = qsq.query_id
JOIN sys.query_store_query_text qsqt ON qsq.query_text_id = qsqt.query_text_id
WHERE qsqt.query_sql_text LIKE '%@%nvarchar(4000)%'
ORDER BY qsrs.avg_cpu_time * qsrs.count_executions DESC;

2. Planes de ejecución en SSMS

Activa «Include Actual Execution Plan» (Ctrl+M) y busca la advertencia CONVERT_IMPLICIT en el operador de búsqueda. Si aparece en el predicado de un Index Scan sobre una columna varchar, has encontrado el problema. También puedes usar Extended Events con el evento sqlserver.plan_affecting_convert para detección en tiempo real.

3. Auditoría del código C#

Busca en tu codebase el patrón que genera el problema:

// Patrón problemático: string anónimo a columna varchar
await connection.QueryAsync<T>(sql, new { algunaColumnaVarchar });

Cualquier llamada a Dapper que pase strings como objeto anónimo contra columnas varchar es un candidato. Prioriza aquellas en rutas de alta frecuencia (endpoints con muchas llamadas por minuto).

Regla de oro y protección del fix

La regla es simple: si la columna es varchar, usa DbType.AnsiString. Si es nvarchar, el DbType.String por defecto está bien. Siempre hacer coincidir el tipo y el tamaño del parámetro con la definición de la columna en la base de datos.

Un punto crítico para equipos: documenta el porqué con un comentario explícito junto al código. Sin él, algún desarrollador bien intencionado simplificará la query de vuelta a new { productCode } durante una refactorización futura, reintroduciendo el problema. La verbosidad de DynamicParameters es una barrera de protección intencional — no una complejidad innecesaria.

Impacto en aplicaciones SaaS y arquitecturas cloud

En el contexto de startups SaaS con arquitectura multi-tenant sobre Azure SQL o SQL Server, este problema se amplifica por el modelo de costos de cloud. Un servidor de base de datos corriendo al 80% de CPU por conversiones implícitas no solo degrada la experiencia del usuario — genera facturas de infraestructura innecesariamente altas y puede obligar a un scale-up prematuro.

La corrección de este issue en una sola query de alta frecuencia puede reducir el uso de CPU del servidor en porcentajes de dos dígitos, postergando la necesidad de escalar verticalmente y mejorando la latencia para todos los tenants simultáneamente. Es uno de los retornos de inversión más altos en optimización de base de datos: cero cambios de schema, cero nuevos índices, solo parámetros correctos.

Conclusión

El mismatch entre C# strings (nvarchar) y columnas varchar en SQL Server es uno de esos bugs que viven en producción por meses o años sin ser detectados porque no genera errores — solo costo. En aplicaciones .NET con Dapper de alta concurrencia, una sola query afectada puede ser responsable de una fracción significativa del CPU total de tu servidor de base de datos.

El fix tiene tres pasos: detectar con Query Store o planes de ejecución, corregir con DbType.AnsiString y DynamicParameters, y proteger con comentarios que expliquen el porqué. Si estás usando Dapper con SQL Server hoy, vale la pena auditar tus queries de alta frecuencia antes de que el problema escale junto con tu base de usuarios.

Descubre cómo otros founders implementan optimizaciones como esta en sus stacks de producción — únete gratis a la comunidad de Ecosistema Startup.

Aprender con founders