Руководство по SQL: как лучше писать запросы

SQL Программа перевода самородков

Руководство по SQL: как лучше писать запросы

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

Вот почему это руководство по SQL проведет вас через следующие шаги для оценки вашего запроса:

  • Во-первых, вы будете работать в области науки о данныхВажность изучения SQLКраткий обзор для начала.
  • Далее вы узнаете больше о том, какОбработка и выполнение SQL-запросов, чтобы вы могли правильно понять важность написания высокопроизводительных запросов: более конкретно, вы увидите, что запросы анализируются, переписываются, оптимизируются и, наконец, выполняются;
  • Имея это в виду, вы можете не только просмотреть некоторыеЗапрос против шаблонаИ вы также можете узнать об альтернативах и решениях, которые могут иметь какие-либо ошибки, вы также узнаете большеКоллекционный или процедурный подходСодержание запроса.
  • Вы также увидите эти анти-шаблоны для проблем с производительностью, и в дополнение к «ручному» подходу к улучшению SQL-запросов вы также можете сделать это более структурированным и углубленным способом, используя некоторые другие инструменты, которые помогут вам просмотреть планы запросовПроанализируйте свой запрос;и,
  • Перед выполнением запроса вы кратко пойметеВременная сложность и нотация Big OЧтобы понять план выполнения, прежде чем выполнить сложность времени запроса; и, наконец,
  • Вы кратко увидите, как ещеСкорректируйте свой запрос.

Вас интересуют курсы SQL? Тогда узнайте о DataCampВведение в SQL для науки о данныхКурс сейчас!

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

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

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

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

Но почему это так часто используется? Почему SQL не уходит, даже если это было в течение длительного времени?

На это есть несколько причин: во-первых, большинство компаний хранят свои данные в системе управления реляционными базами данных (RDBMS) или в системе управления реляционными потоками данных (RDSMS), и вам нужен SQL для доступа к этим данным. SQL — это язык общения данных: он позволяет вам взаимодействовать практически с любой базой данных и даже создавать свои собственные локально!

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

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

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

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

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

Чего же ты ждешь?

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

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

Во-первых, запрос анализируется в «дерево разбора»; запрос анализируется, чтобы увидеть, соответствует ли он синтаксическим и семантическим требованиям. Анализатор создает внутреннее представление входного запроса. Затем выходные данные передаются механизму перезаписи.

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

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

Теперь вам может быть интересно, что такое «хороший план запроса».

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

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

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

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

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

  • WHEREпункт
  • любойINNER JOINилиLEFT JOINКлючевые слова;
  • HAVINGпункт;

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

Однако вы также должны знать, что производительность имеет значение только в реальных сценариях: нет никакого смысла просто говорить, что эти предложения и ключевые слова плохие. Конечно, запрос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оператор, скорее всего, вы не используете index.

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

Если вы не используете индексы, содержащиеся в базе данных, ваши запросы будут выполняться дольше. Вот почему лучше всего найти в запросе, используя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);
  • ВключаютUNIONдваSELECTутверждение.

намекать: Здесь нужно быть осторожным, не используйте его без необходимостиUNIONоператор, который не нужен, поскольку вы будете запрашивать одну и ту же таблицу несколько раз. Кроме того, вы должны знать, что при использованииUNION, время выполнения будет больше.UNIONАльтернативой оператору является: поместить все условия в одноSELECTструктура или использованиеOUTER JOINальтернативаUNIONчтобы перестроить запрос.

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

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

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. Не переборщите с запросами

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

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

  • Условия сокращения соединений

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

будет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, ... Они были сгенерированы из нескольких строк.

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

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

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

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

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

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

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

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

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

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

УведомлениеЕсли вы столкнулись с запросами процедурного типа, вам следует подумать о его переписывании или рефакторинге.

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

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

УведомлениеЕсть также некоторые анти-шаблоны, упомянутые в предыдущем разделе, которые проистекают из соображений производительности, таких какAND,ORиNOTВ операторе отсутствует использование индекса. Размышление о производительности требует не только структурированного подхода, но и более глубокого подхода.

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

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

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

  • Некоторые наборы инструментов для создания графических представлений планов запросов см. в следующем примере:

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

УведомлениеЕсли вы обычно используете PostgreSQL, вы можетеEXPLAINЧтобы различать, здесь вы получаете только описание того, как будет выполняться план запроса, который не был выполнен, иEXPLAIN ANALYZEЗапрос фактически выполняется, а затем возвращается анализ ожидаемого и фактического плана запроса. В общем, фактический план выполнения — это фактический план запроса, и, хотя он логически эквивалентен, фактический план выполнения более полезен, поскольку содержит дополнительные сведения и статистику о том, что на самом деле произошло при выполнении запроса.

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

намекать: если вы хотите узнать больше оEXPLAINДля более подробного взгляда на примеры, рассмотрите возможность чтения этой книги Guillyume Lelarge«Понимание объяснить».

Временная сложность и большое O

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

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

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

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

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

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

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

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

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

Читать далеездесь.

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

Настройка SQL

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

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

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

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

«Мой любимый антишаблон — не тестировать запросы.

Это относится к:

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

  • Вы считаете, что ваш запрос оптимизирован, но не хотите проверять свои предположения.

  • Вы примете первый успешный запрос, вам непонятно, оптимален ли он. "

Если вы хотите начать работу с SQL, рассмотрите возможность изучения DataCamp.Intro to SQL for Data Scienceкурс!

Программа перевода самородковэто сообщество, которое переводит высококачественные технические статьи из Интернета сНаггетсДелитесь статьями на английском языке на . Охват контентаAndroid,iOS,React,внешний интерфейс,задняя часть,продукт,дизайнЕсли вы хотите видеть более качественные переводы, пожалуйста, продолжайте обращать вниманиеПрограмма перевода самородков,официальный Вейбо,Знай колонку.

Категории