Насколько велики издержки на производительность базы данных при использовании LINQ?
-
08-06-2019 - |
Вопрос
Насколько высокие затраты на производительность базы данных связаны с использованием C # и LINQ по сравнению с пользовательскими оптимизированными запросами, загружаемыми в основном на низкоуровневом C, оба с серверной частью SQL Server 2008?
Я конкретно имею в виду здесь случай, когда у вас есть довольно ресурсоемкая программа, и вы будете выполнять обновление данных по крайней мере один раз на экране и будете иметь 50-100 одновременных пользователей.
Решение
По моему опыту, накладные расходы минимальны при условии, что человек, пишущий запросы, знает, что он / она делает, и принимает обычные меры предосторожности, чтобы гарантировать, что сгенерированные запросы являются оптимальными, что необходимые индексы установлены и т.д. И т.п.Другими словами, влияние на базу данных должно быть одинаковым;на стороне приложения накладные расходы минимальны, но обычно незначительны.
Тем не менее...из этого правила есть одно исключение;если один запрос генерирует несколько агрегатов, поставщик L2S преобразует его в большой запрос с одним подзапросом на агрегат.Для большой таблицы это может оказать значительное влияние на ввод-вывод, поскольку стоимость ввода-вывода базы данных для запроса растет на величины для каждого нового агрегата в запросе.
Обходным решением для этого, конечно, является перемещение агрегированных данных в сохраненный proc или view.У Мэтта Уоррена есть несколько примеров кода для альтернативного поставщика запросов, который переводит такого рода запросы более эффективным способом.
Ресурсы:
http://blogs.msdn.com/mattwar/archive/2008/07/08/linq-building-an-iqueryable-provider-part-x.aspx
Другие советы
Спасибо, Стю.Суть, по-видимому, в том, что LINQ to SQL, вероятно, не имеет значительных накладных расходов на производительность базы данных с более новыми версиями, если вы можете использовать скомпилированный select, а более медленные функции обновления, вероятно, будут выполняться быстрее, если у вас нет ДЕЙСТВИТЕЛЬНО опытного эксперта, выполняющего большую часть кодирования.