Трудно понять, какие именно трюки будут работать, к сожалению, не пробуя их.Я бы сказал: «Конечно, попробуйте отключить все что угодно в LINQ-to-SQL» - только вы можете измерить, как это влияет на вашу систему.
Однако;у нас тоже были некоторые проблемы с производительностью материализации в LINQ-to-SQL, поэтому для многих наших критичных к производительности запросов на «чтение» мы написали и переключились на dapper-dot-net .Это гораздо более простой, но очень оптимизированный API для выполнения запросов в объектных моделях.Он не напрямую связан с LINQ-to-SQL, поэтому такие вещи, как отложенная загрузка, работать не будут, но это действительно очень быстро.
Общее использование похоже на ExecuteQuery<T>(sql, args)
функциональность LINQ-to-SQL, за исключением синтаксиса именованных параметров TSQL, который используется вместо строки {0}
/ {1}
. Синтаксис формата, который использует LINQ-to-SQL, т. е.
// insanely simple example purely for illustration
int custId = ...
var orders = conn.Query<Order>(
"select * from Order where CustomerId = @custId",
new { custId });
Если выв настоящее время используется запрос LINQ, вы можете извлечь TSQL несколькими способами:
- трассировка SQL
- соединение
dbContext.Log
- возможно (на устройстве разработчика) до Console.Out
- с использованием
mvc-mini-profiler
, который может эффективно захватывать операции SQL даже на производственном блоке
Мы очень успешно используем этот подход с нашим уже существующим LINQтипы к SQL.