Команды sql запросов: Обзор основных SQL запросов

Вступление

Для работы с различными реляционными базами данных, включая Oracle, MySQL, PostgreSQL, DBase, FoxPro, Clipper, Paradox был создан единый язык запросов к базам данных. Назвали его язык SQL, что означает Structured Query Language — структурированный язык запросов.

В данной статье используем СУБД MySql. Именно для пользователя, СУБД MySql  имеет наибольшее практическое применение, как в управлении различными расширениями, так и в их создании. Как-никак, все локальные сервера, CMS, платформы интернет магазинов работают именно с СУБД MySql.

Понятие и назначение SQL запроса для администрирования БД

Реляционная база данных это таблица с информацией, разнесенной по столбцам (поля или атрибуты) и строкам (записи или кортежи) таблицы. Чтобы изменить или удалить данные в столбцах и строках, а также данные в определенных ячейках (пресечение столбца и строки) можно воспользоваться прикладными инструментами (например, phpmyadmin) или сделать SQL запрос к базе данных, по которому выполнится нужное действие.

Что можно делать с помощью SQL запросов

При помощи запросов SQL можно:

• Создавать таблицы БД;
• Изменять таблицы БД;
• Удалять таблицы БД;
• Вставлять записи (строки) в таблицы БД;
• Редактировать записи в таблицах БД;
• Извлекать выборочную информацию из таблиц БД;
• Удалять выборочную информацию из БД.

Это не полный перечень возможностей SQL запросов, но и он дает представление, что с помощью SQL запросов можно сделать с базой данных всё что необходимо.

Операторы SQL запроса

Язык SQL имеет большой список различных операторов, каждый из которых «задает» определенную команду. Справочник по операторам тут: (http://www.mysql.ru/docs/man/Database_Administration.html/CREATE_TABLE.html). В следующих статьях будем рассматривать, как работают основные операторы SQL и как с их помощью управлять базами данных.

В завершении перечислю, операторы sql запросов, которые будем рассматривать в ближайших статьях раздела:

• CREATE TABLE – оператор sql для создания таблицы базы данных;
• ALTER TABLE – оператор sql для изменения таблицы БД;
• INSERT INTRO – вставка информации (строк) в таблицы БД;
• UPDATE – оператор для редактирования информации в таблицах БД;
• SELECT – извлечение информации из таблиц БД;
• DELET – удаление информации из таблиц БД.

©WebOnTo.ru

Другие статьи раздела: СУБД

Похожие статьи:

SQL для начинающих: первые шаги

Знание SQL существенно облегчает работу любому специалисту, которому необходимы данные для выполнения тех или иных задач. Мы в devtodev подготовили цикл статей, которые познакомят вас с редактором и основными командами SQL. С их помощью вы научитесь применять SQL для анализа данных игр и приложений: работать с датами, вычислять ARPPU и другие монетизационные метрики, определять структуру покупок пользователей и многое другое. Начнем с определения.

SQL (Structured Query Language) – эффективный инструмент, позволяющий обращаться к базам данных (БД) для хранения, получения и обработки информации. Существует заблуждение, что SQL – язык программирования, хотя это не так, и правильнее называть его языком запросов. Составляя запрос к базе данных, мы можем получить прямой доступ к информации о действиях пользователя в игре или приложении. 

Кто работает с SQL? 

Умение составлять SQL-запросы – важный навык для любого аналитика. Даже если в продукт уже интегрирована аналитическая система, бывают нетривиальные случаи, когда ее функционала недостаточно. Тогда специалисты и обращаются к SQL-запросам для работы с сырыми данными напрямую. 

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

Структура данных 

Когда мы говорим про SQL, то сразу же стоит уточнить, что речь будет идти о реляционной БД. Она представляет собой хранилище двумерных таблиц с фиксированным количеством столбцов и неограниченным числом строк. Между собой таблицы могут быть связаны с помощью одинаковых идентификаторов. С их помощью можно объединять разные таблицы и находить нужные данные. Формат таблиц и связи между ними всегда задаются заранее, ещё на этапе проектирования БД. В таких таблицах, например, может содержаться информация о пользователях и обо всех совершенных ими платежах в игровом магазине. 

Как посчитать количество и сумму платежей за три месяца

Разберем базовые команды на примере простого запроса из раздела SQL Report devtodev. Он поможет нам посчитать количество и сумму всех платежей, совершенных за три месяца в игре или приложении. 

select to_char(eventtime, ‘yyyy-mm’) as month
, sum(p.priceusd)*0.7 as revenue 
, count(eventtime) as payments   
from p102968.payments p
where eventtime>=current_date — interval ‘3 month’ and eventtime < current_date  
and tester is false  
and cheater is false  
group by 1
order by 1 asc

SELECT – обязательная команда SQL, которая обращается к базе данных для создания выборки нужных нам столбцов в заданном формате. 

Функция TO_CHAR нужна для преобразования дат или чисел в одну строку, а AS дает имя полю при создании выборки. Таким образом, в примере мы сгруппировали все даты платежей по месяцам. Теперь они будут отображаться с названием “month”.

SUM используется только для числовых столбцов. Здесь мы суммируем все значения столбца

COUNT считает количество строк таблицы. Сосчитав количество строк в столбце eventtime (даты совершения платежей), мы узнаем, сколько всего платежей было совершено в выбранный период времени. 

FROM обязательный элемент запроса, определяющий название таблицы, с которой мы работаем. В SQL отчете devtodev список всех таблиц и столбцов удобно расположен в левом поле. Кликните на название нужного столбца, чтобы добавить его в любой участок запроса.

WHERE добавляет к запросу фильтр по дополнительным условиям. Здесь, с помощью команд CURRENT_DATE — INTERVAL и CURRENT_DATE, а также операторов сравнения (>= и <), мы задали интервал для отчета – последние 3 месяца. 

Логический оператор AND позволяет добавить дополнительные условия к выборке данных, где IS FALSE мы используем для исключения тестировщиков и читеров.

GROUP BY 1 и ORDER BY 1 ASC группируют выдаваемые данные по положению поля в таблице (по первому столбцу) и сортируют по возрастанию. 

Закончив с запросом, смотрим результат:

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

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

Порядок операций SQL — В каком порядке MySQL выполняет запросы?

Если вы ищете короткую версию, это логический порядок операций, также известный как порядок выполнения, для SQL-запроса:

1. FROM, включая JOINs
2. WHERE
3. GROUP BY
4. HAVING
5. Функции WINDOW
6. SELECT
7. DISTINCT
8. UNION
9. ORDER BY
10. LIMIT и OFFSET

Но реальность не так проста и не прямолинейна. Как мы уже говорили, стандарт SQL определяет порядок выполнения для различных предложений SQL-запросов. Сказано, что современные базы данных уже проверяют этот порядок по умолчанию, применяя некоторые приемы оптимизации, которые могут изменить фактический порядок выполнения, хотя в конечном итоге они должны возвращать тот же результат, как если бы они выполняли запрос в порядке выполнения по умолчанию.

Почему они это сделали? Что ж, может быть глупо, если база данных сначала извлечет все данные, упомянутые в предложении FROM (включая JOIN), прежде чем заглядывать в предложение WHERE и его индексы. Эти таблицы могут содержать большое количество данных, поэтому вы можете представить, что произойдет, если оптимизатор базы данных будет придерживаться традиционного порядка операций SQL-запроса.

Давайте рассмотрим каждую из частей SQL-запроса в соответствии с порядком их выполнения.

FROM и JOINs

Таблицы, указанные в предложении FROM (включая JOIN), будут оцениваться первыми, чтобы определить весь рабочий набор, который имеет отношение к запросу. База данных будет объединять данные из всех таблиц в соответствии с предложениями JOINs ON, а также извлекать данные из подзапросов и даже может создавать некоторые временные таблицы для хранения данных, возвращаемых из подзапросов в этом разделе.

Во многих случаях, тем не менее, оптимизатор базы данных сначала выберет оценку части WHERE, чтобы увидеть, какая часть рабочего набора может быть пропущена (предпочтительно с использованием индексов), поэтому он не будет слишком сильно раздувать набор данных, если он действительно не нужен.

Класс WHERE

Предложение WHERE будет вторым, который будет оценен после предложения FROM. У нас есть набор рабочих данных, и теперь мы можем фильтровать данные в соответствии с условиями в предложении WHERE.

Эти условия могут включать ссылки на данные и таблицы из условия FROM, но не могут включать ссылки на псевдонимы, определенные в предложении SELECT, поскольку эти данные и эти псевдонимы могут еще не «существовать» в этом контексте, так как это предложение не было пока оценивается базой данных.

Кроме того, распространенной ошибкой для предложения WHERE является попытка отфильтровать агрегированные значения в предложении WHERE, например, с помощью этого предложения: WHERE sum (available_stock)> 0. Этот оператор не выполнит запрос, потому что агрегаты будут оцениваться позже в процессе (см. Раздел GROUP BY ниже). Чтобы применить условие фильтрации к агрегированным данным, вы должны использовать предложение HAVING, а не предложение WHERE.

Предложение GROUP BY

Теперь, когда мы отфильтровали набор данных с помощью предложения WHERE, мы можем объединить данные в соответствии с одним или несколькими столбцами, появляющимися в предложении GROUP BY. Группировка данных фактически разбивает их на разные порции или сегменты, где каждый сегмент имеет один ключ и список строк, соответствующих этому ключу. Отсутствие предложения GROUP BY похоже на помещение всех строк в одно большое ведро.

После того как вы агрегируете данные, вы можете теперь использовать функции агрегации, чтобы возвращать значение для каждой группы для каждого сегмента. Такие функции агрегации включают COUNT, MIN, MAX, SUM и другие.

Класс HAVING

Теперь, когда мы сгруппировали данные с помощью предложения GROUP BY, мы можем использовать предложение HAVING, чтобы отфильтровать некоторые сегменты. Условия в предложении HAVING могут ссылаться на функции агрегирования, поэтому пример, который не работал в приведенном выше предложении WHERE, будет прекрасно работать в предложении HAVING: HAVING sum (available_stock)> 0.

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

Кроме того, как мы упоминали в предыдущих разделах, псевдонимы, определенные в предложении SELECT, также не могут быть доступны в этом разделе, поскольку они еще не были оценены базой данных (это верно для большинства баз данных).

Функции Window

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

Оконные функции могут использоваться только в предложении SELECT или ORDER BY. Вы можете использовать функции агрегирования внутри оконных функций, например:

SUM(COUNT(*)) OVER ()

Предложение SELECT

Теперь, когда мы закончили отбрасывать строки из набора данных и группировать данные, мы можем выбрать данные, которые мы хотим получить из запроса на стороне клиента. Вы можете использовать имена столбцов, агрегаты и подзапросы внутри предложения SELECT. Имейте в виду, что если вы используете ссылку на функцию агрегации, например COUNT (*) в предложении SELECT, это просто ссылка на агрегацию, которая уже произошла, когда произошла группировка, поэтому сама агрегация не произойдет в предложении SELECT, но это только ссылка на его набор результатов.

Ключевое слово DISTINCT

Синтаксис ключевого слова DISTINCT немного сбивает с толку, потому что ключевое слово занимает свое место перед именами столбцов в предложении SELECT. Но фактическая операция DISTINCT происходит после SELECT. При использовании ключевого слова DISTINCT база данных отбрасывает строки с повторяющимися значениями из оставшихся строк, оставшихся после фильтрации и агрегирования.

Ключевое слово UNION

Ключевое слово UNION объединяет наборы результатов двух запросов в один набор результатов. В большинстве баз данных вы можете выбирать между UNION DISTINCT (который отбрасывает дублирующиеся строки из объединенного набора результатов) или UNION ALL (который просто объединяет наборы результатов без применения какой-либо проверки на дублирование).

Вы можете применить сортировку (ORDER BY) и ограничение (LIMIT) к набору результатов UNION, так же, как вы можете применить его к обычному запросу.

Предложение ORDER BY

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

Вы можете выбрать сортировку данных по убыванию (DESC) или по возрастанию (ASC). Заказ может быть уникальным для каждой из частей заказа, поэтому действует следующее: ORDER BY firstname ASC, age DESC

LIMIT и OFFSET

В большинстве случаев использования (за исключением нескольких подобных отчетов) мы хотели бы отбросить все строки, кроме первых X строк результата запроса. Предложение LIMIT, которое выполняется после сортировки, позволяет нам сделать это. Кроме того, вы можете выбрать, с какой строки начинать извлекать данные и сколько исключать, используя комбинацию ключевых слов LIMIT и OFFSET. В следующем примере будет выбрано 50 строк, начиная с строки 100: LIMIT 50 OFFSET 100

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Порядок выполнения SQL-операций | Techrocks

Перевод статьи «SQL Order of Operations».

Мы привыкли, что компьютер выполняет команды программиста последовательно, в том порядке, который указал автор кода. Однако SQL относится к декларативным языкам, то есть SQL-запрос описывает ожидаемый результат, а не способ его получения.

Давайте разберём, в какой последовательности выполняются шесть операций в SQL: SELECT, FROM, WHERE, GROUP BY, HAVING и ORDER BY.

База данных выполняет команды в строгой очерёдности, о которой полезно знать любому разработчику. Залог оптимального запроса тот же, что и залог успеха в приготовлении вкусного блюда: важно знать не только ингредиенты, но и когда каждый из них должен попасть в блюдо. Если база данных отойдет от стандартного сценария выполнения команд, то ее производительность может сильно пострадать.

База данных сотрудников

В этой статье мы поработаем с типичной базой сотрудников, относящихся к разным отделам. По каждому сотруднику известны его ID, имя, фамилия, зарплата и отдел:

Таблица EMPLOYEE:

Таблица DEPARTMENT:

Проанализировать порядок выполнения команд в запросах помогут типичные задачи:

• Найти имена сотрудников отдела IT
• Посчитать количество сотрудников каждого отдела с зарплатой выше 80 000.

Начнем с получения имён  сотрудников отдела IT:

SELECT LAST_NAME, FIRST_NAME
  FROM EMPLOYEE
 WHERE DEPARTMENT = 'IT'

В первую очередь выполняется FROM EMPLOYEE:

Затем наступает очередь  WHERE DEPARTMENT = ‘IT’, который фильтрует колонку DEPARTMENT:

Наконец,  SELECT FIRST_NAME, LAST_NAME скрывает ненужные колонки и возвращает финальный результат:

Отлично! После первого препарирования выяснилось, что простой запрос с операторами SELECT, FROM, и WHERE выполняется по следующей схеме:

• FROM (выбор таблицы)
• WHERE (фильтрация строк)
• SELECT (возврат результирующего датасета).

Влияние ORDER BY на план выполнения запроса

Допустим, что начальнику не понравился отчет, основанный на предыдущем запросе, потому что он хочет видеть имена в алфавитном порядке. Исправим это с помощью ORDER BY:

SELECT LAST_NAME, FIRST_NAME
    FROM EMPLOYEE
   WHERE DEPARTMENT = 'IT'
ORDER BY FIRST_NAME

Выполняться такой запрос будет так же, как и предыдущий. Только в конце ORDER BY отсортирует строки в алфавитном порядке по колонке FIRST_NAME:

Таким образом, команды SELECT, FROM, WHERE и ORDER BY выполняются в следующей последовательности:

1. FROM (выбор таблицы)
2. WHERE (фильтрация строк)
3. SELECT (возврат результирующего датасета)
4. ORDER BY (сортировка)

GROUP BY и HAVING

Усложним задачу. Посчитаем количество сотрудников каждого отдела с зарплатой выше 80 000 и остортируем результат по убыванию. Нам подойдёт следующий запрос:

SELECT DEPARTMENT, COUNT(*)
    FROM EMPLOYEES
   WHERE SALARY > 80000
GROUP BY DEPARTMENT
ORDER BY COUNT(*) DESC

Как обычно, в первую очередь выполнится FROM EMPLOYEE и вернет сырые данные:

После выполнения WHERE SALARY > 80000 выборка сузится:

Затем применяется GROUP BY. При этом генерируется по одной записи для каждого отдельного значения в указанной колонке. В нашем примере мы создаем по одной записи для каждого отдельного значения колонки DEPARTMENT:

После этого применяется SELECT с COUNT(*), производя промежуточный результат:

Применение ORDER BY завершает выполнение запроса и возвращает конечный результат:

План выполнения данного запроса следующий:

1. FROM (выбор таблицы)
2. WHERE (фильтрация строк)
3. GROUP BY (агрегирование данных)
4. SELECT (возврат результирующего датасета)
5. ORDER BY (сортировка).

Добавим выражение HAVING

HAVING — это аналог WHERE для GROUP BY. С его помощью можно фильтровать агрегированные данные.

Давайте применим HAVING и определим, в каких отделах (за исключением отдела продаж) средняя зарплата сотрудников больше 80 000.

SELECT DEPARTMENT
    FROM EMPLOYEES
   WHERE DEPARTMENT <> 'SALES'
GROUP BY DEPARTMENT
  HAVING AVG(SALARY) > 80000

По уже известной нам схеме сначала выберем все данные из таблицы при помощи FROM EMPLOYEE:

Затем конструкция WHERE избавит нас от данных по отделу SALES:

GROUP BY сгенерирует следующие записи:

HAVING AVG(SALARY) > 80000 ограничит список:

А SELECT вернет финальный результат:

Порядок выполнения для данного запроса следующий:

1. FROM (выбор таблицы)
2. WHERE (фильтрация строк)
3. GROUP BY (агрегирование данных)
4. HAVING (фильтрация агрегированных данных)
5. SELECT (возврат результирующего датасета).

Новый оператор — JOIN

До этого момента мы имели дело с одной таблицей. А что если воспользоваться JOIN  и добавить ещё одну? Выясним фамилии и ID сотрудников, работающих в отделе с бюджетом более 275 000:

SELECT EMPLOYEE_ID, LAST_NAME
  FROM EMPLOYEES
  JOIN DEPARTMENT
    ON DEPARTMENT = DEPT_NAME
 WHERE BUDGET > 275000

FROM EMPLOYEE как обычно запрашивает данные из таблицы EMPLOYEES:

А теперь JOIN запросит сырые данные из DEPARTMENT и скомбинирует данные двух таблиц по условию ON DEPARTMENT = DEPT_NAME:

Потом применяем WHERE BUDGET > 275000:

SELECT EMPLOYEE_ID, LAST_NAME покажет финальный результат:

Для этого запроса план выполнения следующий:

1. FROM (выбор таблицы)
2. JOIN (комбинация с подходящими по условию данными из второй таблицы)
3. WHERE (фильтрация строк)
4. SELECT (возврат результирующего датасета).

Итог

Примеры разных запросов убедительно продемонстрировали, что существует строгий порядок выполнения операций. Но этот порядок может меняться в зависимости от набора команд в запросе. Вот универсальная шпаргалка по очередности выполнения операций в SQL-запросах:

1. FROM (выбор таблицы)
2. JOIN (комбинация с подходящими по условию данными из других таблиц)
3. WHERE (фильтрация строк)
4. GROUP BY (агрегирование данных)
5. HAVING (фильтрация агрегированных данных)
6. SELECT (возврат результирующего датасета)
7. ORDER BY (сортировка).

Помните, что если исключить из этого списка один из операторов, то план выполнения может измениться.

SQL Server. Оптимизация запросов SQL. MS SQL Медленно работают запросы SELECT

Введение

В данном руководстве мы изложили некоторые рекомендации по оптимизации запросов SQL. 

Оптимизация структуры таблиц SQL Server

Разбивайте сложные таблицы на несколько, помните, чем больше в вашей таблице столбцов и тяжелых типов (nvarchar(max)), тем тяжелее по ней проход. Если некоторые данные не всегда используются в select с ней, выносите их отдельно в таблицу и связывайте через FK

Выберите правильные типы данных. Всегда выбирайте самый маленький тип для данных, которые Вы должны хранить в столбце.

Если текстовые данные в столбце имеют разную длину, используйте тип  данных NVARCHAR вместо NCHAR.

Не используйте NVARCHAR или NCHAR типы данных, если Вы не должны сохранить 16-разрядные символьные данные (UNICODE). Они требуют в два раза больше места, чем CHAR и VARCHAR, что повышает расходы времени на ввод-вывод (но если у вас кириллица, то без NVARCHAR не обойтись).

Если Вы должны хранить большие строки данных и их длина меньше чем 8,000 символов, используют тип данных NVARCHAR вместо TEXT. Текстовые поля требуют больше ресурсов для обработки и снижают производительность.

Любое поле, в котором должны быть только отличные от нуля значения, нужно объявлять как NOT NULL

Для любого поля, которое должно содержать уникальные значения, стоит указать модификатор UNIQUE

Хранение изображений в БД нежелательно. Храните в таблице путь к файлу (локальный путь или URL), а сам файл помещайте в файловую систему сервера. 

Оптимизация запросов SELECT 

Не читайте больше данных, чем надо. Не используйте *

Если ваше приложение позволяет пользователям выполнять запросы, но вы не можете отсечь лишние сотни и тысячи возвращаемых строк, используйте оператор TOP внутри инструкции SELECT. 

Не возвращайте клиенту большее количество столбцов или строк, чем действительно необходимо (Не используй * в Select). 

Как можно раньше отфильтруйте данные. Не нужно выполнять большой тяжелый подзапрос для  всех строк таблицы. Сначала отфильтруйте нужные строки.

Корректно используйте JOIN

Если Вы имеете две или более таблиц, которые часто объединяются вместе, тогда столбцы, используемые для объединений должны иметь соответствующий индекс.

Для лучшей производительности, столбцы, используемые в объединениях должны иметь одинаковые типы данных. И если возможно, это должны быть числовые типы данных, вместо символьных типов.

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

Если Вы должны регулярно объединять четыре или более таблиц, для получения recordset’а, попробуйте денормализовать таблицы так, чтобы число таблиц, участвующих в объединении уменьшилось. Часто, при добавлении одного или двух столбцов из одной таблицы в другую, объединения могут быть уменьшены.

Тип JOIN используйте только тот, который вернет вам НЕОБХОДИМЫЕ данные без каких-либо дублей или лишней информации (или совсем отказаться от join). Т.е. не нужно получать всех пользователей таким образом: 

select users.username from users
inner join roles on users.roleID=roles.id

В этом случае вы получите много повторов пользователей

Сортировка в SELECT

Самой ресурсоемкой сортировкой является сортировка строк.

При объявлении полей всегда следует использовать размер, который нужен, и не выделять лишние байты про запас.

Группирование в SELECT

Используйте как можно меньше колонок для группировки.

По возможности лучше использовать Where вместо Having, т.к. это уменьшает количество строк для группировки на ранней стадии. 

Если требуется группирование, но без использования агрегатных функций (COUNT(), MIN(), MAX и т.д.), разумно использовать DISTINCT.

Ограничить использование DISTINCT

Эта команда исключает повторяющиеся строки в результате. Команда требует повышенного времени обработки. Лучше всего комбинировать с LIMIT.

Ограничить использование SELECT для постоянно изменяющихся таблиц.

Возможно имеет смысл сохранять промежуточные агрегированные данные в какой-то другой таблице, которая обновляется менее часто чем таблица изменений (например, таблица логов).

Оптимизация WHERE в запросе SELECT

Если where состоит из условий, объединенных AND,  они должны располагаться в порядке возрастания вероятности истинности данного условия. Чем быстрее мы получим false  в одном из условий — тем меньше условий будет обработано и тем быстрее выполняется запрос. 

Если where состоит из условий, объединенных OR,  они должны располагаться в порядке уменьшения вероятности истинности данного условия. Чем быстрее мы получим true  в одном из условий — тем меньше условий будет обработано и тем быстрее выполняется запрос. 

Исопльзуйте IN вместо OR. Операция IN работает гораздо быстрее, чем серия OR.  Запрос «… WHERE column1 = 5 OR column1 = 6» медленнее чем «…WHERE column1 IN (5, 6)». 

Используйте Exists вместо Count >0 в подзапросах. Используйте where exists (select id from t1 where id = t.id) вместо where count(select id from t1 where id=t.id) > 0

LIKE. Эту операцию следует использовать только при крайней необходимости, потому что лучше и быстрее использовать поиск, основанный на full-text индексах. 

Советы по оптимизации хранимых процедур и SQL пакетов

Инкапсулируйте ваш код в хранимых процедурах

Для обработки данных используйте хранимые SQL процедуры.

Когда хранимая процедура выполняется в первый раз (и у нее не определена опция WITH RECOMPILE), она оптимизируется, для нее создается план выполнения запроса, который кешируется SQL сервером. Если та же самая хранимая процедура вызывается снова, она будет использовать кешированный план выполнения запроса, что экономит время и увеличивает производительность. 

Всегда включайте в ваши хранимые процедуры инструкцию «SET NOCOUNT ON». Если Вы не включите эту инструкцию, тогда каждый раз при выполнении запроса SQL сервер отправит ответ клиенту, указывающему число строк, на которые воздействует запрос.

Избегайте использования курсоров

По возможности выбирайте быстрый forward-only курсор

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

Когда Вы закончили использовать курсор, как можно раньше не только ЗАКРОЙТЕ (CLOSE) его, но и ОСВОБОДИТЕ (DEALLOCATE).

Используйте триггеры c осторожностью

Триггеры — это усложнение логики работы приложения, неявное неожиданное выполнение дополнительных действий. 

Триггеры усложняют интерфейс хранимых процедур. Поместите все необходимые проверки и действия в рамки хранимых процедур. 

Временные таблицы для больших таблиц, табличные переменные — для малых (меньше 1000)

Если вам требуется хранить промежуточные данные в таблицах, то используйте табличные переменные (@t1) для малых таблиц, а временные таблицы (#t1) — для больших. 

Подробнее: 

Сравнение временных таблиц, табличных переменных и обобщенных табличных выражений (CTE)

https://coderoad.ru/27894/%D0%92-%D1%87%D0%B5%D0%BC-%D1%80%D0%B0%D0%B7%D0%BD%D0%B8%D1%86%D0%B0-%D0%BC%D0%B5%D0%B6%D0%B4%D1%83-%D0%B2%D1%80%D0%B5%D0%BC%D0%B5%D0%BD%D0%BD%D0%BE%D0%B9-%D1%82%D0%B0%D0%B1%D0%BB%D0%B8%D1%86%D0%B5%D0%B9-%D0%B8-%D1%82%D0%B0%D0%B1%D0%BB%D0%B8%D1%87%D0%BD%D0%BE%D0%B9-%D0%BF%D0%B5%D1%80%D0%B5%D0%BC%D0%B5%D0%BD%D0%BD%D0%BE%D0%B9-%D0%B2-SQL-Server

При определении временной таблицы имеет смысл проверить ее на существование: 

IF OBJECT_ID('tempdb..#eventIDs') IS NOT NULL begin
   DROP TABLE #eventIDs
end
CREATE TABLE #eventIDs ( id int primary key,instanceID	int )
     

Также для улучшения быстродействия используйте для временной таблицы первичный ключ и индексы. 

Как уменьшить вероятность дедлоков на базе

Дедлок — это взаимная блокировка 2 выполняющихся пакетов sql. Это самым негативным образом сказывается на быстродействии запросов. 

Чтобы избежать deadlocks, пытайтесь разрабатывать ваше приложение с учетом следующих рекомендаций:

• Всегда получайте доступ к объектам в одном и том же порядке.
• Старайтесь делать транзакции короткими и заключайте их в один пакет (batch)
• Старайтесь использовать максимально низкий уровень изоляции для пользовательского соединения, которое работает с транзакцией.

Работа с индексами SQL Server

Советы по созданию кластерных индексов

• Первичный ключ не всегда должен быть кластерным индексом. Если Вы создаете первичный ключ, тогда SQL сервер автоматически делает первичный ключ кластерным индексом. Первичный ключ должен быть кластерным индексом, только если он отвечает одной из нижеследующих рекомендаций.
• Кластерные индексы идеальны для запросов, где есть выбор по диапазону или вы нуждаетесь в сортированных результатах. Так происходит потому, что данные в кластерном индексе физически отсортированы по какому-то столбцу. Запросы, получающие выгоду от кластерных индексов, обычно включают в себя операторы BETWEEN, <, >, GROUP BY, ORDER BY, и агрегативные операторы типа MAX, MIN, и COUNT.
• Кластерные индексы хороши для запросов, которые ищут запись с уникальным значением (типа номера служащего) и когда Вы должны вернуть большую часть данных из записи или всю запись. Так происходит потому, что запрос покрывается индексом.
• Кластерные индексы хороши для запросов, которые обращаются к столбцам с ограниченным числом значений, например столбцы, содержащие данные о странах или штатах. Но если данные столбца мало отличаются, например, значения типа «да/нет», «мужчина/женщина», то такие столбцы вообще не должны индексироваться.
• Кластерные индексы хороши для запросов, которые используют операторы GROUP BY или JOIN.
• Кластерные индексы хороши для запросов, которые возвращают много записей, потому что данные находятся в индексе, и нет необходимости искать их где-то еще.
• Избегайте помещать кластерный индекс в столбцы, в которых содержатся постоянно возрастающие величины, например, даты, подверженные частым вставкам в таблицу (INSERT). Так как данные в кластерном индексе должны быть отсортированы, кластерный индекс на инкрементирующемся столбце вынуждает новые данные быть вставленным в ту же самую страницу в таблице, что создает «горячую зону в таблице» и приводит к большому объему дискового ввода-вывода. Постарайтесь найти другой столбец, который мог бы стать кластерным индексом.

Советы по выбору некластерных индексов

• Некластерные индексы лучше подходят для запросов, которые возвращают немного записей (включая только одну запись) и где индекс имеет хорошую селективность (более чем 95 %).
• Если столбец в таблице не содержит по крайней мере 95% уникальных значений, тогда очень вероятно, что Оптимизатор Запроса SQL сервера не будет использовать некластерный индекс, основанный на этом столбце. Поэтому добавляйте некластерные индексы к столбцам, которые имеют хотя бы 95% уникальных записей. Например, столбец с «Да» или «Нет» не имеет 95% уникальных записей.
• Постарайтесь сделать ваши индексы как можно меньшего размера (особенно для многостолбцовых индексов). Это уменьшает размер индекса и уменьшает число чтений, необходимых, чтобы прочитать индекс, что увеличивает производительность.
• Если возможно, создавайте индексы на столбцах, которые имеют целочисленные значения вместо символов. Целочисленные значения имеют меньше потерь производительности, чем символьные значения.
• Если Вы знаете, что ваше приложение будет выполнять один и тот же запрос много раз на той же самой таблице, рассмотрите создание покрывающего индекса на таблице. Покрывающий индекс включает все столбцы, упомянутые в запросе. Из-за этого индекс содержит все данные, которые Вы ищете, и SQL сервер не должен искать фактические данные в таблице, что сокращает логический и/или физический ввод — вывод. С другой стороны, если индекс становится слишком большим (слишком много столбцов), это может увеличить объем ввода — вывода и ухудшить производительность.
• Индекс полезен для запроса только в том случае, если оператор WHERE запроса соответствует столбцу (столбцам), которые являются крайними левыми в индексе. Так, если Вы создаете составной индекс, типа «City, State», тогда запрос » WHERE City = ‘Хьюстон’ » будет использовать индекс, но запрос » WHERE State = ‘TX’ » не будет использовать индекс.
• Любая операция над полем в предикате поиска, которое лежит под индексом, сводит на нет его использование. where isnull(field,’’) = ‘’ здесь индекс не используется, where field = ‘’ and field is not null — здесь используется.

Бывает ли слишком много индексов?

Да. Проблема с лишними индексами состоит в том, что SQL сервер должен изменять их при любых изменениях таблицы (INSERT, UPDATE, DELETE).

Лучшим решением ставить сомнительный индекс или нет, будет подождать и собрать статистику по работе индексов.

Лучшие кандидаты на установку индекса

• Это поля, по которым идет Join
• Поля связи, участвующие в подзапросах
• Поля, по которым идет фильтрация в where
• Поля, по которым выполняется сортировка.

Советы по использованию временных таблиц и табличных переменных

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

• Временная таблица храниться физически в tempdb, табличная переменная хранится в памяти SQL
• SQL может сам решить сохранить табличную переменную физически, если там будет много данных, это потеря ресурсов, учтите это
• Временная таблица для большого объема данных (полноценная выборка), табличная переменная для малого (справочники или набор ID для чего-то)
• Временная таблица доступна из любой процедуры SQL, табличная переменная только в рамках запроса. Не забывайте очищать временные таблицы после их использования

Если вы SQL-разработчик или администратор MS SQL Server, и вы хотели бы разрабатывать веб-решения на SQL, то веб-платформа Falcon Space — это то, что вам нужно.

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

Вводная статья по Falcon Space для SQL специалиста

Не удается найти страницу | Autodesk Knowledge Network

(* {{l10n_strings.REQUIRED_FIELD}})

{{l10n_strings.CREATE_NEW_COLLECTION}}*

{{l10n_strings.ADD_COLLECTION_DESCRIPTION}}

 ВЫБЕРИТЕ имя, фамилию, страну
  ОТ Заказчика
 ГДЕ Страна = 'Италия'
 

  ВЫБЕРИТЕ имя, фамилию, страну
  ОТ Заказчика
 ГДЕ Страна = 'Италия'
  

ВЫБЕРИТЕ имена столбцов
  ОТ имя-таблицы
 ГДЕ условие
 ORDER BY sort-order
 

 ВЫБЕРИТЕ имя, фамилию, город, страну
  ОТ Заказчика
 ГДЕ Город = 'Париж'
 ЗАКАЗАТЬ ПО ФАМИЛИ
 

  ВЫБЕРИТЕ имя, фамилию, город, страну
  ОТ Заказчика
 ГДЕ Город = 'Париж'
 ЗАКАЗАТЬ ПО ФАМИЛИ
  

ВСТАВИТЬ имя-таблицы (имена-столбцов)
ЗНАЧЕНИЯ (значения столбцов)
 

 INSERT Supplier (CompanyName, ContactName, City, Country)
ЦЕННОСТИ ('Oxford Trading', 'Ian Smith', 'Oxford', 'UK')
 

  ВСТАВИТЬ Поставщик (название компании, контактное имя, город, страна)
ЦЕННОСТИ («Оксфорд Трейдинг», «Ян Смит», «Оксфорд», «Великобритания»)
  

ОБНОВЛЕНИЕ имя-таблицы
   УСТАНОВИТЬ имя-столбца = значение-столбца
 ГДЕ условие
 

 ОБНОВЛЕНИЕ OrderItem
   НАБОР Количество = 2
 ГДЕ Id = 388
 

  ОБНОВЛЕНИЕ OrderItem
   НАБОР Количество = 2
 ГДЕ Id = 388
  

УДАЛИТЬ имя-таблицы
 ГДЕ условие
 

 УДАЛИТЬ элемент заказа
 ГДЕ OrderId = 117
 

  УДАЛИТЬ элемент заказа
 ГДЕ OrderId = 117