Подсказки в Sql Server
Действительно ли подсказки необходимы для каждого оператора sql? У нас есть dba, который неравнодушен к этому и просит нас помещать подсказки для каждого оператора select и update в наших сохраненных процедурах. Это действительно необходимо?
Иногда, когда обычным людям дают полномочия, они становятся немного глупыми.
Ответы 5
Как правило, не. Надевать их на все - это излишне.
документация говорит
Поскольку оптимизатор запросов SQL Server обычно выбирает лучший план выполнения для запроса, мы рекомендуем использовать join_hint, query_hint и table_hint только в крайнем случае опытными разработчиками и администраторами баз данных.
Подсказки - это просто подсказки. Они помогают оптимизатору выполнять работу наилучшим образом. Но, как и при любой оптимизации, вы должны сосредоточиться на утверждениях, которые на самом деле являются проблемами.
В этом случае подсказки переопределяют любой план выполнения, который оптимизатор запросов может выбрать для запроса, поэтому они больше, чем просто обычная «подсказка».
Да, но я хочу сказать, что запрос будет работать без подсказок. Требовать, чтобы в каждом запросе были подсказки, просто глупо.
Это не правда. SQL Server довольно строго подчиняется подсказкам.
Ваш администратор базы данных - неправильный.
От РС:
Because the SQL Server query optimizer typically selects the best execution plan for a query, we recommend that join hint, query hint, and table hint be used only as a last resort by experienced developers and database administrators.
Хм .. Он «неправ», если говорит, что они необходимы. Если он просто хочет, чтобы они отвечали на каждый вопрос, это может сделать его анальным, но не «неправильным».
@James, если администратор базы данных просит их добавлять подсказки в каждый запрос выбора и обновления, то я думаю, что он ошибается. Нет?
Обычно это просто наоборот. Однако, в зависимости от вашей ситуации, это может быть желательно.
Например, у нас есть одна база данных (фактически, набор баз данных на одном сервере), где все данные представляют собой ночной дамп снимка системы мэйнфрейма, используемый для отчетности и других целей. Помимо пакетного процесса, который воссоздает базы данных каждую ночь, ничего такого выполняет любую запись в эту систему. В этом контексте схема блокировки по умолчанию не подходит, и политика между нашей группой и ИТ-группой, которая управляет всеми нашими серверами, не позволяет нам изменить ее. Итак: почти все запросы к этим базам данных содержат подсказки with (nolock).
Я предполагаю, что есть и другие ситуации, когда у вас могут быть базы данных отчетов без записи, или, возможно, наоборот: база данных архивирования или журналирования, которая редко читается. Дело в том, что иногда может быть настроена специализированная база данных, где схема блокировки по умолчанию не подходит, и вы не можете ее изменить. Тогда тебе понадобится куча пиньят ... Я имею в виду подсказки.
Но это исключение, подтверждающее правило. В целом оптимизатор базы данных умнее, чем вы, когда дело касается таких вещей, как блокировка.
Зависит - оптимизатор запросов делает довольно хороший выбор намерений. Какие подсказки требует ваш администратор базы данных? @Ned немного ошибается - подсказка явно указывает оптимизатору не определять путь, а использовать вместо этого вашу оптимизацию.
Законодательство о том, что вы должны всегда или никогда не использовать подсказки, в некоторой степени игнорирует проблемы, которые нужно решить с помощью подсказок. Некоторые случаи, когда подсказки имеют решающее значение:
- NOLOCK для явного снятия блокировки чтения из таблиц поиска домена, запрашиваемых в рамках транзакции.
- привязка плана запроса к определенному индексу из-за "дрейфа" статистики во время интенсивных обновлений (в этом случае план вернулся к сканированию таблицы на 10-метровой таблице, а не к кластеризованному индексу)
Никогда не приходилось использовать подсказки соединения.
Не могли бы вы привести несколько примеров подсказок, которые ему требуются?