Cómo ejecutar sentencias SQL en la base de datos
Cuando ejecutamos la declaración SQL en la capa de datos, la aplicación se conectará al servidor de base de datos correspondiente y enviará la declaración SQL al servidor. para su procesamiento.
Paso 2: El servidor analiza la declaración SQL solicitada
Caché del plan SQL, los usuarios que usan con frecuencia Query Analyzer pueden ser conscientes del hecho de que la primera vez que se ejecuta la declaración de consulta. El tiempo de ejecución de esta declaración tiende a ser extremadamente largo, pero si la misma declaración se ejecuta inmediatamente o durante un período de tiempo, los resultados de la consulta se devolverán en muy poco tiempo. El motivo es:
Después de recibir la solicitud de consulta, el servidor no ingresará inmediatamente a la base de datos para realizar la consulta, sino que verificará si el plan de ejecución correspondiente existe en el caché del plan de la base de datos. Si existe, el plan de ejecución compilado se llama directamente, ahorrando así tiempo de compilación del plan de ejecución.
Si la fila consultada ya existe en el búfer de datos, no es necesario consultar el archivo físico, sino obtener los datos del búfer, de modo que la velocidad de obtención de los datos de la memoria será más rápido que leer los datos del disco duro. Mucho más rápido, mejorando así la eficiencia de las consultas. El almacenamiento en búfer de datos se mencionará más adelante.
Si no hay un plan de ejecución correspondiente en el caché del plan SQL, el servidor primero verificará la sintaxis de la declaración SQL solicitada por el usuario. Si hay un error de sintaxis, el servidor finalizará la operación de consulta. y devolver el plan de ejecución correspondiente a la aplicación que lo llamó.
Nota: El mensaje de error devuelto solo contendrá errores de sintaxis básicos, como selección escrita como selec, etc. Si el mensaje de error contiene una columna que no está presente en la lista, el servidor no la verificará porque esto es solo una validación de sintaxis y la semántica será correcta en el siguiente paso.
Una vez que se cumplan los requisitos de sintaxis, el servidor comenzará a verificar si su semántica es correcta. Por ejemplo, si los nombres de las tablas, los nombres de las columnas, los procedimientos almacenados y otros objetos de la base de datos realmente existen, si se descubre que algún objeto no existe, se informa un error a la aplicación y se finaliza la consulta.
El siguiente paso es obtener el bloqueo de análisis del objeto. Cuando consultamos una tabla, el servidor primero bloqueará el objeto. Esto es para garantizar la unidad de los datos. aunque hay datos insertados en este momento, sin embargo, debido a que no hay bloqueo, el registro consultado se leyó y la transacción se revertirá debido al error de inserción, lo que provocará una lectura sucia.
El siguiente paso es verificar los permisos del usuario de la base de datos. Si la sintaxis y la semántica de la declaración SQL son correctas, es posible que no se obtenga el resultado de la consulta en este momento. Si el usuario de la base de datos no tiene los derechos de acceso correspondientes, el servidor informará un error de permisos insuficientes a la aplicación. Un proyecto un poco más grande, a menudo Un proyecto contendrá varias cadenas de conexión de base de datos. Estos usuarios de la base de datos son diferentes. Cada uno de estos usuarios de la base de datos tiene permisos diferentes. Algunos tienen permisos de solo lectura, algunos tienen permisos de solo lectura. permisos de escritura. Se deben seleccionar diferentes según las diferentes operaciones a ejecutar. No importa cuán bien escrita y perfecta esté su declaración SQL, no ayudará si no tiene cuidado.
El último paso del análisis es determinar el plan de ejecución final. Cuando se verifican la sintaxis, la semántica y los permisos, el servidor no le devuelve los resultados inmediatamente, sino que optimiza su SQL y selecciona diferentes algoritmos de consulta para devolverlo a la aplicación de la forma más eficiente. Por ejemplo, al realizar una consulta de unión de tablas, el servidor finalmente decidirá si utilizar hashjoin, mergejoin o loop join en función del costo general, qué índice será más eficiente, etc. Sin embargo, sus capacidades de optimización automática son limitadas y no pueden escribir consultas SQL eficientes ni optimizar sus declaraciones de consulta SQL.
Cuando se determina el plan de ejecución, el plan de ejecución se guardará en la memoria caché del plan SQL. La próxima vez que se ejecute la misma solicitud, se recuperará directamente de la memoria caché del plan para evitar volver a compilar el plan de ejecución. .
Paso 3: Ejecución de la declaración
Una vez que el servidor haya terminado de analizar la declaración SQL, sabrá qué significa realmente la declaración y luego ejecutará la declaración SQL.
Hay dos situaciones en este momento:
Si la declaración de consulta contiene filas de datos que se han leído en el búfer de datos, el servidor leerá los datos directamente desde el búfer de datos y devolverlo a la aplicación, evitando así leer datos de archivos físicos y mejorando la velocidad de consulta.
Si no hay una fila de datos en el búfer de datos, el servidor leerá la fila de datos del archivo físico y la devolverá a la aplicación, y luego escribirá la fila de datos en el búfer de datos para su próximo uso.
Nota: Existen muchos tipos de cachés SQL, si estás interesado puedes buscar aquí. A veces, la existencia del caché dificulta que el efecto de optimización aparezca de inmediato, porque la segunda ejecución será particularmente rápida debido a la existencia del caché, por lo que el caché generalmente se elimina primero y luego se reduce el rendimiento antes y después de la optimización. comparado Los siguientes son varios métodos comúnmente utilizados:
1
DBCC DROPCLEANBUFFERS
2
Elimina todos los buffers borrados del grupo de buffers. .
3
DBCC FREEPROCCACHE
4
Elimina todos los elementos de la caché del proceso.
5
DBCC FREESYSTEMCACHE
6
Libera todas las entradas de caché no utilizadas de todos los cachés.
El motor de base de datos de SQL Server 2005 limpia de antemano las entradas de caché no utilizadas en segundo plano para dejar memoria disponible para la entrada actual. Sin embargo, puede utilizar este comando para eliminar manualmente las entradas no utilizadas de todos los cachés.
Esto básicamente elimina el impacto del caché SQL, no parece haber una solución para eliminar completamente el caché, así que si alguien tiene una solución así, sugiérala.
Orden de ejecución:
La cláusula FROM devuelve el conjunto de resultados inicial.
La cláusula WHERE excluye registros que no cumplen con los criterios de búsqueda.
La cláusula GROUP BY recopila los registros seleccionados en grupos de valores únicos en la cláusula GROUP BY.
La función agregada especificada en la lista de selección calcula el valor agregado para cada grupo.
Además, la cláusula HAVING excluye registros que no cumplen con los criterios de búsqueda.
Evalúa todas las expresiones;
Utilice ORDER BY para ordenar el conjunto de resultados.
Encuentra el campo a buscar.
Cómo ejecutar sentencias SQL en la base de datos
Etiqueta: