Как C#‑строки и Dapper тихо убивают индексы Microsoft SQL Server

[aamonster]

Для меня выглядит как баг SQL Server (и workaround для этого бага). Не вижу никакой причины для него перебирать все записи, а не учесть при поиске тип столбца (если надо – выполнив дополнительную проверку для найденных кандидатов).

[Tzimie]

Нет, не баг. Тип приводится от простого к более сложному, то есть varchar приводится к nvarchar, а не наоборот.

[aamonster]

Прекрасно. Пусть приводится – но не при поиске по индексу, а при возврате результата. Т.е. пришёл нам nvarchar – приводим его к varchar (с потерей данных), ищем по нему (используя индекс), найденные приводим к nvarchar и сравниваем с образцом. Опционально можно оптимизировать: если при приведении в varchar и обратно обратно образец меняется – сразу "not found", даже не проверяя индекс. По-моему, очевидное решение, и делать его должны разработчики SQL Server.
Но при его отсутствии, понятно, приходится костылить (и, главное, вообще помнить о таких gotcha).

[Stol-Stul]

Неужели там разработчики идиоты и мазохисты сидят?

[aamonster]

Возможно, legacy и сложно менять. Или жалоб не было (хотя это и маловероятно).

[amironov]

Неявное преобразование -- зло в любом языке. По-хорошему в таких случаях должно как минимум предупреждение кидаться.

[alexander-java]

Есть такая книга "настройка (оптимизация, tuning) sql " . Это типичная проблема при работе с индексами, неявное преобразование.

[amironov]

Как C#‑строки и Dapper тихо убивают ваши индексы сервера SQL

SQL Server лучше не переводить, так как речь идеть про конкретный продукт, а не про все SQL СУБД.

[stranger777]

Поправил, спасибо. Пока уточнял, нашёл глобальное решение, если везде уместны ANSI‑строки:

Dapper.SqlMapper.AddTypeMap(typeof(string), System.Data.DbType.AnsiString);

Проблема старая.

[elmanaw]

Во. Я уже в готовности был проверять подобные запросы с Postgresql)