Hibernate Query vs Criteria Performance

Question

Recientemente tuve un fenómeno bastante extraño. Tuve que obtener un recuento que incluye uniones en varias tablas con diferentes condiciones WHERE. Implementé la consulta primero con los criterios API de hibernación. Creó correctamente la instrucción SQL preparada solicitada, pero fue bastante lenta. Re-implementé entonces toda la consulta usando HQL. Fue bastante desagradable hacerlo, pero el resultado fue mucho más rápido que con la API de Criteria. ¿Alguien sabe el motivo de ese comportamiento? Supuse que Criteria y HQL Framework usan la misma base de código para transformarlo a SQL.

Ésta es la consulta:

select count(*) from R r where r.ISREPLACEDBY = 0 
and r.STATUS='OK' and r.A = ? 
and r.C in 
    (select distinct RC from CX cx where cx.FROMDATE >= ? and cx.FROMDATE <=?) 

Answer 1

Supongo que finalmente encontré el motivo. Parece que el criterio api crea nuevos nombres de variables cada vez que se ejecuta una declaración preparada. La base de datos (en nuestro caso, DB2) calcula un nuevo plan de ejecución de consulta cada vez que se ejecuta la instrucción. Por otro lado, HQL usa los mismos nombres de variable, lo que permite que la base de datos reutilice los planes de ejecución de consultas.

Answer 2

por lo general creen que HQL está muy cerca óptima, ya que es casi recta SQL con algunas sustituciones. Supongo que la traducción de HQL a SQL es solo una sustitución; la API Criteria probablemente genera HQL para luego transformarse. En general, HQL es tu mejor apuesta.

Answer 3

Criterios de Hibernate utilizar la reflexión para generar statments SQL

Answer 4

---

criterios, en teoría debería tener menos sobrecarga que una consulta HQL (a excepción de consultas con nombre, que voy a llegar a). Esto se debe a que Criteria no necesita analizar nada. Las consultas HQL se analizan con un analizador basado en ANTLR y luego el AST resultante se convierte en SQL. Sin embargo, con HQL/JPAQL puede definir consultas con nombre, donde el SQL se genera cuando se inicia SessionFactory. En teoría, las consultas con nombre tienen menos sobrecarga que Criteria. Por lo tanto, en términos de gastos generales de SQL generación tenemos:

1. Named HQL/JPAQL consultas - la generación de SQL sucede sólo una vez.
2. Criterios: no es necesario analizar antes de generar.
3. (sin nombre) HQL/JPAQL Query - Parse, luego generar. Dicho esto, la elección de una técnica de consulta basada en la sobrecarga del análisis sintáctico y la generación de SQL es probablemente un error en mi opinión. Esta sobrecarga suele ser muy pequeña en comparación con la realización de una consulta real en un servidor de base de datos real con datos reales. Si esta sobrecarga realmente aparece al crear el perfil de la aplicación, entonces tal vez debería cambiar a una consulta con nombre.

Estas son las cosas que considerar al decidir entre Criteria y HQL/JPAQL:

• En primer lugar, usted tiene que decidir si estás bien con tener una dependencia de la API de Hibernate propietaria en su código. JPA no tiene Criteria.
• criterios es muy bueno en el manejo de muchos parámetros de búsqueda opcional tal como se puede encontrar en una página web típica con un multi-parámetro 'búsqueda' . Con HQL, los desarrolladores tienden a virar en la cláusula expresiones con StringBuilder (¡evitar esto!). Con Criteria, usted no necesita hacer eso.
• HQL/JPAQL se puede utilizar para la mayoría de otras cosas, porque el código tiende a ser más pequeño y más fácil para los desarrolladores a entender.
• consultas frecuentes Realmente se pueden convertir en consultas con nombre si se utiliza HQL. Prefiero hacer esto más tarde, después de algunos perfiles.

Usted puede leer algo de información adicional aquí http://tech.puredanger.com/2009/07/10/hibernate-query-cache/