Язык структурированных запросов (SQL) - незаменимый навык в индустрии науки о данных, и, вообще говоря, освоить этот навык довольно легко. Однако большинство забывает, что SQL - это не только написание запросов, что является лишь первым шагом на этом пути. Другое дело - убедиться, что запросы эффективны или соответствуют контексту, в котором вы работаете.

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

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

Вас интересует курс SQL? Пройдите курс DataCamp Введение в SQL для науки о данных!

Почему я должен изучать SQL для науки о данных?

SQL еще не мертв: это один из самых востребованных навыков, который вы найдете в описаниях должностей в отрасли науки о данных, независимо от того, претендуете ли вы на должность аналитика данных, инженера данных, ученого данных или любых других ролей. . Это подтверждают 70% респондентов, опрошенных O’Reilly Data Science Salary Survey 2016, которые указали, что используют SQL в своем профессиональном контексте. Более того, в этом обзоре SQL намного превосходит языки программирования R (57%) и Python (54%).

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

Неплохо для языка, который был разработан в начале 1970-х, правда?

Но почему именно он так часто используется? И почему он не умер, хотя существует уже так давно?

Есть несколько причин: одна из первых причин заключается в том, что компании в основном хранят данные в системах управления реляционными базами данных (СУБД) или в системах управления реляционными потоками данных (RDSMS), и вам нужен SQL для доступа к этим данным. SQL - это язык данных: он дает вам возможность взаимодействовать практически с любой базой данных или даже создавать свою собственную локально!

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

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

Если вы действительно хотите провести сравнение, считайте это изучением линейной алгебры: приложив все усилия к этому одному предмету, вы знаете, что сможете использовать его и для овладения машинным обучением!

Короче говоря, вам следует изучить этот язык запросов:

  • Его довольно легко освоить даже для новичков. Кривая обучения довольно проста и постепенна, так что вы будете писать запросы в кратчайшие сроки.
  • Он следует принципу «учись один раз, используй где угодно», так что это отличное вложение вашего времени!
  • Это отличное дополнение к языкам программирования; В некоторых случаях написание запроса даже предпочтительнее написания кода, потому что оно более производительно!
  • …

Чего ты все еще ждешь? :)

Обработка SQL и выполнение запросов

Чтобы повысить производительность вашего SQL-запроса, вы сначала должны знать, что происходит внутри, когда вы нажимаете ярлык для выполнения запроса.

Сначала запрос анализируется в «дерево синтаксического анализа»; Запрос анализируется на предмет соответствия синтаксическим и семантическим требованиям. Парсер создает внутреннее представление входного запроса. Этот вывод затем передается механизму перезаписи.

Тогда задача оптимизатора - найти оптимальное выполнение или план запроса для данного запроса. План выполнения точно определяет, какой алгоритм используется для каждой операции и как координируется выполнение операций.

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

Теперь вы, вероятно, задаетесь вопросом, что считается «хорошим планом запроса».

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

Затем выполняется выбранный план запроса, который оценивается механизмом выполнения системы, и возвращаются результаты вашего запроса.

Из предыдущего раздела, возможно, не стало ясно, что принцип Garbage In, Garbage Out (GIGO) естественным образом проявляется в процессе обработки и выполнения запроса: тот, кто формулирует запрос, также владеет ключами к производительности ваших SQL-запросов. Если оптимизатор получит плохо сформулированный запрос, он сможет сделать только столько ...

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

Идеальная отправная точка - подумать о «точках» в ваших запросах, где могут возникнуть проблемы. И, как правило, есть четыре пункта и ключевых слов, по которым новички могут ожидать возникновения проблем с производительностью:

  • Предложение WHERE;
  • Любые INNER JOIN или LEFT JOIN ключевые слова; А также,
  • Предложение HAVING;

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

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

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

1. Получите только те данные, которые вам нужны

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

Вот почему обычно рекомендуется обращать внимание на оператор SELECT, предложение DISTINCT и оператор LIKE.

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

Если у вас есть коррелированные подзапросы с EXISTS, вам следует попытаться использовать константу в операторе SELECT этого подзапроса вместо выбора значения фактического столбца. Это особенно удобно, когда вы проверяете только существование.

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

Рассмотрим следующий пример, чтобы понять, что подразумевается под использованием константы:

SELECT driverslicensenr, name 
FROM Drivers 
WHERE EXISTS (SELECT '1' FROM Fines 
              WHERE fines.driverslicensenr = drivers.driverslicensenr);

Совет: полезно знать, что коррелированный подзапрос - не всегда хорошая идея. Вы всегда можете избавиться от них, например, переписав их с помощью INNER JOIN:

SELECT driverslicensenr, name 
FROM drivers 
INNER JOIN fines ON fines.driverslicensenr = drivers.driverslicensenr;

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

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

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

2. Ограничьте свои результаты

Если вы не можете избежать фильтрации вашего SELECT оператора, вы можете рассмотреть возможность ограничения результатов другими способами. Здесь на помощь приходят такие подходы, как предложение LIMIT и преобразование типов данных.

Вы можете добавить в запросы предложения LIMIT или TOP, чтобы установить максимальное количество строк для набора результатов. Вот некоторые примеры:

SELECT TOP 3 * FROM Drivers;

Обратите внимание, что вы можете дополнительно указать PERCENT, например, если вы измените первую строку запроса на SELECT TOP 50 PERCENT *.

SELECT driverslicensenr, name FROM Drivers LIMIT 2;

Кроме того, вы также можете добавить предложение ROWNUM, что эквивалентно использованию LIMIT в вашем запросе:

SELECT * 
FROM Drivers 
WHERE driverslicensenr = 123456 AND ROWNUM <= 3;

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

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

Альтернативный вариант - как можно больше избегать преобразования типов данных. Также обратите внимание, что не всегда возможно удалить или опустить преобразование типа данных из ваших запросов, но вы обязательно должны быть осторожны при их включении и что когда вы это сделаете, вы протестируете эффект добавления перед запуском запроса. .

3. Не делайте запросы сложнее, чем они должны быть.

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

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

Когда вы используете в запросе оператор OR, скорее всего, вы не используете индекс.

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

Если вы не используете индексы, включенные в базу данных, выполнение вашего запроса неизбежно займет больше времени. Вот почему лучше искать альтернативы использованию оператора OR в вашем запросе;

Рассмотрим следующий запрос:

SELECT driverslicensenr, name 
FROM Drivers 
WHERE driverslicensenr = 123456 OR driverslicensenr = 678910 OR driverslicensenr = 345678;

Вы можете заменить оператора на:

SELECT driverslicensenr, name 
FROM Drivers 
WHERE driverslicensenr IN (123456, 678910, 345678);
  • Два SELECT оператора с UNION.

Совет: здесь нужно быть осторожным, чтобы не использовать операцию UNION без необходимости, потому что вы просматриваете одну и ту же таблицу несколько раз. В то же время вы должны понимать, что когда вы используете UNION в своем запросе, время выполнения увеличивается. Альтернативы операции UNION: переформулировать запрос таким образом, чтобы все условия помещались в одну SELECT инструкцию, или использование OUTER JOIN вместо UNION.

Совет: имейте в виду, что, хотя OR и другие операторы, которые будут упомянуты в следующих разделах, скорее всего, не используют индекс, поиск по индексу не всегда является предпочтительным!

Если ваш запрос содержит оператор NOT, скорее всего, индекс не используется, как и в случае с оператором OR. Это неизбежно замедлит ваш запрос. Если вы не знаете, что здесь имеется в виду, рассмотрите следующий запрос:

SELECT driverslicensenr, name FROM Drivers WHERE NOT (year > 1980);

Этот запрос определенно будет выполняться медленнее, чем вы могли бы ожидать, главным образом потому, что он сформулирован намного сложнее, чем он мог бы быть: в таких случаях, как этот, лучше искать альтернативу. Попробуйте заменить NOT операторами сравнения, такими как >, <> или !>; Приведенный выше пример действительно может быть переписан и выглядеть примерно так:

SELECT driverslicensenr, name FROM Drivers WHERE year <= 1980;

Это уже выглядит лучше, не так ли?

Оператор AND - это еще один оператор, который не использует индекс и может замедлить ваш запрос, если используется слишком сложным и неэффективным способом, как в примере ниже:

SELECT driverslicensenr, name 
FROM Drivers 
WHERE year >= 1960 AND year <= 1980;

Лучше переписать этот запрос и использовать оператор BETWEEN:

SELECT driverslicensenr, name 
FROM Drivers 
WHERE year BETWEEN 1960 AND 1980;

Также следует соблюдать осторожность с операторами ALL и ALL, поскольку при их включении в запросы индекс не будет использоваться. Альтернативы, которые здесь пригодятся, - это функции агрегирования, такие как MIN или MAX.

Совет: в случаях, когда вы используете предложенные альтернативы, вы должны знать, что все функции агрегирования, такие как SUM, AVG, MIN, MAX по многим строкам, могут привести к длительному запросу. . В таких случаях вы можете попытаться либо минимизировать количество обрабатываемых строк, либо предварительно вычислить эти значения. Вы еще раз видите, что важно знать свою среду, цель вашего запроса ... когда вы принимаете решение, какой запрос использовать!

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

SELECT driverslicensenr, name 
FROM Drivers 
WHERE year + 10 = 1980;

Это выглядит круто, да? Вместо этого попробуйте пересмотреть расчет и переписать запрос примерно так:

SELECT driverslicensenr, name 
FROM Drivers 
WHERE year = 1970;

4. Нет грубой силы

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

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

  • Избыточные условия при присоединении

Когда вы добавляете слишком много условий в свои объединения, вы в основном обязываете SQL выбирать определенный путь. Однако может быть так, что этот путь не всегда наиболее эффективен.

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

Если вы ищете альтернативу, рассмотрите возможность использования предложения WHERE. Рассмотрим следующие вопросы:

SELECT state, COUNT(*) FROM Drivers WHERE state IN ('GA', 'TX') GROUP BY state ORDER BY state
SELECT state, COUNT(*) FROM Drivers GROUP BY state HAVING state IN ('GA', 'TX') ORDER BY state

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

Вы видите, что речь идет не об ограничении набора результатов, а об ограничении промежуточного числа записей в запросе.

Обратите внимание, что разница между этими двумя предложениями заключается в том, что предложение WHERE вводит условие для отдельных строк, а предложение HAVING вводит условие для агрегатов или результатов выбора, когда один результат, например поскольку MIN, MAX, SUM,… было создано из нескольких строк.

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

Этот список был лишь небольшим обзором некоторых анти-паттернов и советов, которые, надеюсь, помогут новичкам; Если вы хотите узнать, что более опытные разработчики считают наиболее частыми антипаттернами, ознакомьтесь с этим обсуждением.

Основанные на наборах и процедурные подходы к запросам

В приведенных выше анти-шаблонах подразумевается тот факт, что они фактически сводятся к разнице в подходах, основанных на наборах, и процедурных подходах к построению ваших запросов.

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

Примером этого являются избыточные условия в соединениях или случаи, когда вы злоупотребляете предложением HAVING, как в приведенных выше примерах, в которых вы запрашиваете базу данных, выполняя функцию, а затем вызывая другую функцию, или вы используете логику, которая содержит циклы, условия , Определяемые пользователем функции (UDF), курсоры,… для получения окончательного результата. При таком подходе вы часто обнаруживаете, что запрашиваете подмножество данных, затем запрашиваете другое подмножество из данных и так далее.

Неудивительно, что этот подход часто называют «пошаговым» или «построчным» запросом.

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

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

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

Обратите внимание: если вы когда-нибудь столкнетесь с процедурным запросом, вам следует подумать о его переписывании или рефакторинге.

От запроса к планам выполнения

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

Обратите внимание также, что некоторые из антишаблонов, упомянутых в последнем разделе, были связаны с проблемами производительности, такими как операторы AND, OR и NOT и их недостаточное использование индекса. Думая о производительности, требуется не только более структурированный, но и более глубокий подход.

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

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

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

  • В некоторых пакетах есть инструменты, которые создают графическое представление плана запроса. Взгляните на этот пример:

  • Другие инструменты смогут предоставить вам текстовое описание плана запроса. Одним из примеров является инструкция EXPLAIN PLAN в Oracle, но имя инструкции зависит от СУБД, с которой вы работаете. В другом месте вы можете найти EXPLAIN (MySQL, PostgreSQL) или EXPLAIN QUERY PLAN (SQLite).

Обратите внимание: если вы работаете с PostgreSQL, вы делаете различие между EXPLAIN, где вы просто получаете описание, в котором говорится о том, как планировщик намеревается выполнить запрос, не выполняя его, а EXPLAIN ANALYZE на самом деле выполняет запрос и возвращает вам анализ ожидаемого и фактического планов запроса. Вообще говоря, фактический план выполнения - это план, в котором вы фактически выполняете запрос, тогда как предполагаемый план выполнения определяет, что он будет делать без выполнения запроса. Хотя логически эквивалентный, фактический план выполнения гораздо более полезен, поскольку он содержит дополнительные сведения и статистику о том, что на самом деле произошло при выполнении запроса.

В оставшейся части этого раздела вы узнаете больше о EXPLAIN и ANALYZE и о том, как вы можете использовать эти два, чтобы узнать больше о вашем плане запроса и возможной производительности вашего запроса.

Совет: если вы хотите узнать больше о EXPLAIN или более подробно ознакомиться с примерами, подумайте о том, чтобы прочитать книгу Понимание объяснения, написанную Гийомом Леларжем.

Сложность времени и большой O

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

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

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

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

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

Как вы видели ранее, план выполнения определяет, среди прочего, какой алгоритм используется для каждой операции, что позволяет логически выразить время выполнения каждого запроса как функцию размера таблицы, включенной в план запроса, на который ссылаются как функция сложности. Другими словами, вы можете использовать нотацию большого O и свой план выполнения, чтобы оценить сложность запроса и производительность.

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

Подсказка: индексы здесь - часть истории!

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

Подробнее здесь.

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

Настройка SQL

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

  • Замените ненужное сканирование полной таблицы больших таблиц сканированием индекса;
  • Убедитесь, что вы применяете оптимальный порядок соединения столов;
  • Убедитесь, что вы используете индексы оптимально; А также
  • Кешируйте полные просмотры таблиц малых таблиц.

Поздравляю! Вы дочитали до конца этого сообщения в блоге, которое только что дало вам небольшой обзор производительности SQL-запросов. Надеюсь, вы получили больше информации об анти-шаблонах, оптимизаторе запросов и инструментах, которые вы можете использовать для просмотра, оценки и интерпретации сложности вашего плана запроса. Однако есть еще много чего! Если вы хотите узнать больше, подумайте о прочтении книги «Системы управления базами данных», написанной Р. Рамакришнаном и Дж. Герке.

Наконец, я не хочу скрывать эту цитату пользователя StackOverflow:

«Мой любимый антипаттерн - это не проверка ваших запросов.

Это применимо, когда:

- Ваш запрос включает более одной таблицы.

- Вы думаете, что у вас есть оптимальный дизайн запроса, но не пытаетесь проверить свои предположения.

- Вы принимаете первый работающий запрос, не имея ни малейшего представления о том, близок ли он к оптимизации ».

Если вы хотите начать работу с SQL, подумайте о прохождении курса DataCamp Введение в SQL для науки о данных!

Первоначально опубликовано на www.datacamp.com.