Каковы преимущества и недостатки превращения NOCOUNT прочь в запросах SQL-сервера?
Почему бы не сделать это?
if (!Session::has('name'))
{
$sessionTimeout = 1;
}
Если сеанс истекает, имя больше не будет установлено. Затем вы можете написать код для ответа на $ sessionTimeout == 1;
5 ответов
От SQL BOL:
УСТАНАВЛИВАЕТ NOCOUNT НА, предотвращает отправку сообщений DONE_IN_PROC клиенту для каждого оператора в хранимой процедуре. Для хранимых процедур, которые содержат несколько операторов, которые не возвращают много фактических данных, , установка SET NOCOUNT к НА может обеспечить значительное повышение производительности , потому что сетевой трафик значительно уменьшается.
См. http://msdn.microsoft.com/en-us/library/ms189837.aspx для получения дополнительной информации.
кроме того, эта статья о SQLServerCentral является большой на этом предмете:
Эффекты Производительности NOCOUNT
И это не просто сетевой трафик, который уменьшается. Существует повышение, внутреннее к SQL Server, потому что план выполнения может быть оптимизирован из-за сокращения дополнительного запроса для выяснения, сколько строк было затронуто.
Это просто останавливает сообщение, которое показывает, что # строк, произведенных для того, чтобы быть, отправил/отобразил, который обеспечивает производительность преимущество, особенно если у Вас есть много операторов, которые возвратят сообщение. Это улучшает производительность, так как меньше данных отправляется по сети (между SQL-сервером и фронтэндом).
[еще 112] в BOL: NOCOUNTНАБОРА
У меня всегда есть он набор к НА по причинам выше, но если у Вас есть больше чем 1 набор результатов в Вашем proc, это могло бы испортить клиентский код
Мне лично нравится поворачиваться NOCOUNT на для запросов, которые выполняются ручным способом, и используйте много из Print операторы для вывода сообщений отладки. Таким образом Ваш вывод посмотрел бы меньше как:
Updating usernames (287 rows updated) Done Updating passwords (287 rows updated) Done Doing the next thing (1127 rows updated) Done
И больше как
Updating usernames Done Updating passwords Done Doing the next thing Done
В зависимости от чувствительности того, что Вы обновляете, иногда полезно включать количества; однако, для сложных сценариев с большим выводом мне обычно нравится пропускать их.