A menudo, en la red se pueden encontrar código como este:que es más rápido? Declaración o PreparedStatement
private static final String SQL = "SELECT * FROM table_name";
....
y para esta consulta SQL se utiliza PreparedStatement. ¿Por qué?
Como sé, PreparedStatement dedica tiempo para precompilar la declaración de SQL. Resulta que el Statement es más rápido que un PreparedStatement. ¿O estoy equivocado?
Las declaraciones preparadas son mucho más rápidas cuando tiene que ejecutar la misma instrucción varias veces, con datos diferentes. Eso es porque SQL validará la consulta solo una vez, mientras que si solo usa una declaración validará la consulta cada vez.
La otra ventaja del uso de PreparedStatements es evitar causar una vulnerabilidad de inyección SQL, aunque en su caso su consulta es tan simple que no la ha encontrado.
Para su consulta, la diferencia entre ejecutar una declaración preparada vs una declaración es probablemente insignificante.
EDITAR: En respuesta a su comentario a continuación, tendrá que mirar de cerca la clase DAO para ver qué está haciendo. Si, por ejemplo, cada vez que se llama al método, vuelve a crear la declaración preparada, entonces perderá cualquier beneficio de utilizar las declaraciones preparadas.
Lo que quiere lograr es la encapsulación de su capa de persistencia para que no haya una llamada específica a MySQL o Postgres o lo que esté utilizando, y al mismo tiempo aprovechar los beneficios de rendimiento y seguridad de cosas como declaraciones preparadas. Para hacer esto, necesita confiar en los propios objetos de Java, como PreparedStatement ,.
Yo personalmente crearía mi propia clase DAO para realizar operaciones CRUD, utilizando Hibernate debajo y la API Java Persistence para encapsularlo todo, y eso debería usar declaraciones preparadas para los beneficios de seguridad. Si tiene un caso de uso específico para hacer operaciones repetidas, entonces me inclinaría a envolverlo dentro de su propio objeto.
Hibernate se puede configurar para usar cualquier proveedor de base de datos que esté utilizando a través de un archivo XML, y de esta manera proporciona una encapsulación realmente nítida de su capa de persistencia. Sin embargo, ¡es un producto bastante complicado hacer las cosas bien!
La mayoría de las consultas de tiempo no son tan simples como en su ejemplo. Si hay alguna variación en la consulta, es decir, cualquier parámetro que no se conozca en tiempo de compilación, debe usar PreparedStatement para evitar vulnerabilidades de inyección de SQL. Esto supera cualquier problema de rendimiento. Si hay alguna diferencia entre PreparedStatement y Statement, sería altamente dependiente del controlador JDBC particular en cuestión y la mayoría de las veces la penalización será insignificante en comparación con el costo de ir a la base de datos, ejecutando consultas reales y recuperando resultados. .
sí, dices las cosas obvias. Pero en esta consulta no necesitamos establecer ningún parámetro, y en base a eso, no tendremos inyección de SQL. – Ifozest
Así que sí, como otros han dicho que si no hay parámetros y solo se ejecuta una vez, puede ser un poco más rápido hacer una declaración en lugar de una declaración preparada, pero prefiero ser constante y usar siempre PreparedStatement. –
Más rápido no es la consideración aquí. El análisis del sql generalmente será una pequeña parte de la ejecución general. Vea más en When should we use a PreparedStatement instead of a Statement?
Según mi conocimiento PreparedStatement es mucho más rápido que la declaración. Aquí algunas razones por las que la declaración preparada es más rápida que la declaración, lea para obtener más detalles.
JDBC API proporciona la funcionalidad de conectividad con la base de datos. Luego tratamos de ejecutar la consulta con el uso de la declaración y la declaración preparada.
Hay cuatro pasos para ejecutar la consulta.
Análisis de la consulta sql.
Compilar esta consulta.
optimización de la ruta de adquisición de datos.
ejecutar la consulta.
La interfaz de instrucciones es adecuada cuando no es necesario ejecutar la consulta varias veces.
Desventajas de Statement Interface. hacker puede piratear fácilmente los datos. Al igual que supongamos que tenemos una consulta que tiene el nombre de usuario y la contraseña es un parámetro que puede dar los parámetros adecuados es username = '[email protected]' y contraseña = 'abc123' en realidad esto es actual Pero el hacker puede hacer username = 'abc @ example.com 'o' 1 '= 1 y contraseña =' 'eso significa que puede iniciar sesión correctamente. así que eso está sucediendo posible en la Declaración.
Y sql valida cada vez que recuperamos los datos de la base de datos.
Así que Java tiene la solución para este problema anterior que es PreparedStatement. Esta interfaz tiene muchas ventajas. las principales ventajas de preparedstatement es sql no valida la consulta cada vez. para que pueda obtener el resultado rápido. por favor lea a continuación más ventajas de la declaración preparada.
1) Podemos proporcionar con seguridad el valor de los parámetros de la consulta con el método setter. 2) evita la inyección SQL porque se escapa automáticamente de los caracteres especiales. 3) Cuando usamos la declaración anterior, cuatro pasos se ejecutan cada vez Pero cuando usamos el PreparedStatement, solo se ejecutan los últimos pasos, por lo tanto, esto es más rápido que la instrucción.
Me gustaría aclarar algo. En mi aplicación web simple tengo clase DAO. En esta clase tengo el método (tomar información por ID) que usa preparadoStatement. Al invocar este método varias veces, ¿cuántas veces prepareStatement compilará previamente esta consulta SQL? – Ifozest
He editado mi respuesta principal para esto: es una parte interesante de su pregunta. – christophmccann
ver edición ahora para más información. – christophmccann