Я имею в виду, что в терминах SQL-запросов они компилируются или интерпретируются на низком уровне ?. Как это работает внутри, это оператор SQL, интерпретируемый или скомпилированный ?.Является ли СУБД (MySQL, SQL Server ....) Интерпретированным или скомпилированным?
Это, как правило, работает следующим образом:
SQL String ---[Optimizer]---> Execution Plan ---[Execution]---> Result
Я лично хотел бы видеть оптимизатор (планировщик запросов) как-то очень похожее на компилятор. Он преобразует инструкцию SQL в нечто более легко исполняемое. Однако на чипе не работает исполняемый файл. Эта «компиляция» довольно дорога - так же, как компиляция кода на C++. Это та часть, где оцениваются различные варианты исполнения; порядок соединения, какой индекс использовать и т. д. Рекомендуется избегать этого, когда это возможно, используя параметры привязки .
Затем план выполнения взят на исполнение для базы данных. Однако стратегия уже исправлена. выполнение просто делает это. Эта часть интерпретирует план выполнения, а не SQL.
В конце концов, это как-то похоже на Java или .NET, где компиляция превращает исходный код в двоичную форму, которую легче интерпретировать. Если мы проигнорируем JIT для этого аргумента, выполнение программы Java интерпретирует этот метакод.
Я использовал этот способ, чтобы объяснить преимущество using bind parameters for (Oracle) performance в моем free eBook "Use The Index, Luke".
Пожалуйста, исправьте меня, если я ошибаюсь. Возможно, вы захотите добавить, что оптимизатор может использовать кеширование для плана выполнения, что объясняет преимущество параметров привязки. – bvh
В современных средах SQL это поэтапный подход, когда вы принимаете решение на определенном уровне рабочего процесса, хотите ли вы повторно использовать существующий скомпилированный блок или повторно запустить все этапы, если у вас есть лучший план для определенная комбинация аргументов.
Я думаю, что это отплата между (повторно) compiletime и временем выполнения (затем скомпилированного для исполняемого кода) результата. В зависимости от сложности запроса перекомпиляция, использующая специфику данных аргументов во время выполнения, может не стоить усилий, если время выполнения существующего кода уже низкое из-за предсказуемого минимального потребления ресурсов (например, чтение двух строк и возврат).
С более высокой сложностью запросов и предполагаемым потреблением ресурсов (многие огромные таблицы, решающий выбор индекса, возможное сканирование таблицы), гранулярность вашей статистики вступает в игру. т. е. если у вас есть избирательность, выбросы, селективность диапазона, сред. размеры полей, размеры физических карт и т. д. оптимизатор может прийти к совершенно иным выводам с различными наборами аргументов.
Вычисление наилучшего плана для инструкции 25-join с аргументами переменной 10 ++ может занять свое время и ресурсы. Если результат быстрее и эффективнее, чем версия для всех, это стоит усилий. Особенно это заданный набор аргументов может содержать смены игр, и запрос будет повторно выполняться часто.
И, наконец, ваш пробег может отличаться для каждого продавца;)
Вы спрашиваете о MySQL конкретно или о любой СУБД? Поскольку разные СУБД находятся в разных точках спектра compile-vs-интерпретации – einpoklum