Es decir, en términos de las consultas SQL, ¿se compilan o interpretan en un nivel bajo ?. ¿Cómo funciona internamente, es una instrucción SQL interpretada o compilada ?.¿Se ha interpretado o compilado un DBMS (MySQL, SQL Server ....)?
Se suele trabajar de esta manera:
SQL String ---[Optimizer]---> Execution Plan ---[Execution]---> Result
Personalmente, me gusta ver el optimizador (planificador de consulta) como algo muy similar a un compilador. Está transformando la declaración SQL en algo que es más fácil de ejecutar. Sin embargo, no es natividad ejecutable en el chip. Esta "compilación" es bastante costosa, al igual que la compilación del código C++. Esa es la parte donde se evalúan las diferentes variantes de ejecución; la orden de unión, qué índice usar, y así sucesivamente. Es una buena práctica evitar esto siempre que sea posible utilizando los parámetros de vinculación .
El plan de ejecución se ejecuta para su ejecución por la base de datos. Sin embargo, la estrategia ya está arreglada. la ejecución solo lo está haciendo. Esta parte es una especie de interpretación del plan de ejecución, no del SQL.
Después de todo, es, de alguna manera, similar a Java o .NET, donde la compilación convierte el código fuente en una forma binaria que se puede interpretar más fácilmente. Si ignoramos JIT para este argumento, la ejecución de un programa Java está interpretando este meta-código.
He utilizado esta forma de explicar el beneficio de using bind parameters for (Oracle) performance en mi free eBook "Use The Index, Luke".
Corrígeme si me equivoco: es posible que desee agregar que el Optimizador puede usar el almacenamiento en caché para el plan de ejecución, lo que explicaría la ventaja de los parameter. – bvh
En entornos SQL modernos, es un enfoque por etapas donde toma una decisión en un cierto nivel del flujo de trabajo, desee o no volver a utilizar y bloque compilado existente o inicie todas las etapas nuevamente si obtiene un mejor plan para una cierta combinación de argumentos.
Creo que es una compensación entre el tiempo de compilación y el tiempo de ejecución del código (compilado a ejecutable). Dependiendo de la complejidad de la consulta, una recompilación aplicando los detalles de los argumentos dados en el tiempo de ejecución puede no valer la pena si el tiempo de ejecución del código existente ya es bajo debido al consumo mínimo previsible de recursos (por ejemplo, leer dos filas y regresar).
Con una mayor complejidad de la consulta y el consumo estimado de recursos (muchas tablas enormes involucradas, elección de índice crucial, posible escaneo de tabla), la granularidad de sus estadísticas entra en juego. es decir, si tiene selectividades, valores atípicos, selectividades de rango, prom. tamaños de campo, tamaños de mapas físicos, etc. el optimizador puede llegar a conclusiones muy diferentes con diferentes conjuntos de argumentos.
Calcular el mejor plan para una sentencia de 25 uniones con argumentos de variable 10 ++ puede tomar su tiempo y recursos. Si el resultado es más rápido y más eficiente que la versión única, vale la pena el esfuerzo. Especialmente, el conjunto de argumentos dado puede contener cambiadores de juego y la consulta se volverá a ejecutar con frecuencia.
Por último, su kilometraje puede variar con cada proveedor;)
lo preguntas sobre MySQL en concreto, o cualquier DBMS? Debido a que diferentes DBMS están en diferentes puntos en el espectro de compilación versus interpretación – einpoklum