Microsoft SQL Server

24 сентября была представлена первая редакция CTP выпуска SQL Server 2019, и, позвольте сказать, что он переполнен всевозможными улучшениями и новыми возможностями (многие из которых можно найти в форме предварительного просмотра в базе данных SQL Azure). У меня была исключительная возможность познакомиться с этим чуть раньше, позволившая мне расширить представление об изменениях, пусть даже поверхностно. Вы можете также ознакомиться с последними публикациями от команды разработчиков SQL Server и обновленной документацией .

Индексы — это первое, что необходимо хорошо понимать в работе SQL Server, но странным образом базовые вопросы не слишком часто задаются на форумах и получают не так уж много ответов. Роб Шелдон отвечает на эти, вызывающие смущение в профессиональных кругах, вопросы об индексах в SQL Server: одни из них мы просто стесняемся задать, а прежде чем задать другие сначала подумаем дважды. Основы индексов в SQL Server Одним из важнейших путей достижения высокой производительности SQL Server является использование индексов.

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

Сегодня я хочу предложить читателям 10 рекомендаций по настройке, которые помогут увеличить производительность SQL Server на 90%. Оптимизировать производительность Microsoft SQL Server 2000 и SQL Server 7.0 не так-то просто, но в большинстве случаев администратор может добиться неплохих результатов, приложив совсем немного усилий.

Хотя мощное оборудование сервера может способствовать повышению производительности, разработка приложения и баз данных могут сыграть решающую роль в суммарной эффективности. Помните, что трата денег на "железо" не всегда решает проблемы с производительностью. Многие предполагают, что оборудование сервера, с которым они работают, установлено и конфигурировано правильно.

По умолчанию каждый раз после выполнения хранимой процедуры сервер посылает клиентскому приложению сообщение о количестве строк, обработанных процедурой. Это информация очень редко нужна для клиента. Если отключить эту серверную функцию, то можно уменьшить сетевой трафик между сервером и клиентом, увеличить производительность запроса на сервере.

При использовании команды UNION учтите, что на всем возвращаемом наборе по умолчанию выполняется эквивалент команды SELECT DISTINCT. Иначе говоря - проверяется наличие повторяемых строк. Если вы уверены, что дублирующих записей в результате вашего запроса не будет, то используйте конструкцию UNION ALL.

Время выполнения триггера зависит от количества таблиц, указанных в триггере, и количеству записей, обрабатываемых во время запуска триггера. Поэтому всегда старайтесь уменьшить количество запрашиваемых таблиц и используемых записей в триггере. Если триггер выполняет SELECT из таблиц, не забудьте включить необходимые индексы.

Одним из вопросов, все чаще обсуждаемых мной в последние дни с клиентами или администраторами/разработчиками баз данных, является создание такой политики компании, которая бы описывала ряд стандартов, которым должны следовать при создании хранимых процедур для SQL server. С одной стороны, политика стандартов уровня компании или подразделения не должна быть столь ограничительной или 'высеченной на камне', чтобы душить всякий творческий потенциал, который часто необходим для решения требований бизнеса, стоящих перед разработчиками. С другой стороны, она должна обеспечить такие рекомендации, которые ограничивали стиль кодирования таким образом, чтобы он не создавал проблем безопасности, падения производительности или проблем обслуживании в будущем.

Один из лучших способов повысить эффективность запросов JOIN - ограничить количество записей требуемых для соединения. Возвращайте только те записи, которые будут объединяться, не более того. Если таблица часто используется в запросах JOIN, имеет смысл создать для каждого соединяемого столбца свой собственный индекс.