СУБД (MySQL, SQL Server….) Интерпретируется или компилируется?

Question

Я имею в виду, с точки зрения запросов SQL, они компилируются или интерпретируются на низком уровне? Как это работает внутри? Это оператор SQL, интерпретируемый или скомпилированный?.

Answer 1

Обычно это работает так:

    SQL String ---<b>[Optimizer]</b>---> Execution Plan ---<b>[Execution]</b>---> Result

Мне лично нравится видеть оптимизатор (планировщик запросов) чем-то очень похожим на компилятор. Это превращает оператор SQL в нечто, что будет легче выполнять. Тем не менее, это не исполняемый код на чипе. Эта «компиляция» довольно дорогая, как и компиляция кода C ++. Это та часть, где оцениваются разные варианты исполнения; порядок соединения, какой индекс использовать и так далее. Рекомендуется избегать этого всякий раз, когда это возможно, используя параметры привязки .

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

В конце концов, это как-то похоже на Java или .NET, где компиляция превращает исходный код в двоичную форму, которую легче интерпретировать. Если мы игнорируем JIT для этого аргумента, выполнение Java-программы интерпретирует этот метакод.

---

Я использовал этот способ, чтобы объяснить преимущества использования параметров связывания для производительности (Oracle) в моей бесплатной электронной книге "Use The Index, Luke" .

Answer 2

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

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

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

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

Наконец, ваш пробег может варьироваться в зависимости от поставщика;)